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PREFACE 


The  National  Airspace  Data  Interchange  Network  (NADIN)  is  being  developed,  in  its 
initial  phases,  as  a  common  data  communications  network  that  will  integrate  various  FAA 
communications  services,  specifically  those  involved  in  the  exchange  of  information 
pertaining  to  air  traffic  control.  The  initial  design  was  specifically  directed  to  the 
absorption  of  the  Aeronautical  Fixed  Telecommunication  Network  (AFTN),  NASNET,  and 
most  of  Service  B.  The  design  also  provided  for  the  expansion  of  NADIN  facilities  and 
circuits  so  as  to  accommodate  growth,  both  in  terms  of  requirements  for  included  services 
and  in  terms  of  additional  services. 

Concurrently  with  efforts  to  implement  the  initial  NADIN  design,  efforts  have  been 
directed  to  the  analysis  of  other  services  that  might  be  integrated  into  NADIN.  These 
analyses  have  two  major  objectives.  First  they  are  to  determine  if  the  integration  of  the 
specific  service  into  NADIN  is  cost/benefieial.  Second,  they  are  to  determine  the  specific 
enhancements  to  NADIN  that  would  be  required  to  absorb  that  service.  These  efforts  have 
already  led  to  the  specification  of  an  enhanced  NADIN,  referred  to  as  NADIN  IA,  which  also 
includes  communications  support  for  the  Flight  Service  Automation  System  (FSAS),  Flight 
Data  Input/Output  (FDIO)  equipment,  Automated  Flow  Control  (AFC)  and  the  National 
Flight  Data  Center  Information  System  (NFDC/IS).  Current  FAA  plans  call  for  the 
implementation  of  NADIN  I A  in  1983. 

Studies  of  further  possible  enhancements  are  continuing.  This  report  documents  such 
an  analysis  conducted  with  respect  to  the  Computer  B  (NAS-NAS)  service. 
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SECTION  1 


INTRODUCTION 


1.1  SUMMARY  OF  RESULTS 

Enhancement  of  the  National  Airspace  Data  Interchange  Network  (NADIN)  to  provide 
effective  support  for  Computer  B  (NAS- NAS)  communications  is  feasible  and  cost-effective. 

This  is  the  major  finding  from  the  comparative  analysis  of  alternative  approaches  to 
NAS-NAS  communications  support.  This  and  other  related  findings  have  led  to  the  following 
conclusions: 

Conclusion  1:  NAS-NAS  communications  should  be  incorporated  into  NADIN  before 

the  NAS  9020  computers  are  replaced. 

The  architecture  of  the  current  Computer  B  (NAS-NAS)  Network  would  have  to  be 
significantly  altered  in  order  to  facilitate  replacement  of  enroute  computers  (expected 
about  1988)  and  to  support  other  planned  modifications  to  the  enroute  computer  system.  In 
comparison,  NADIN,  which  can  be  enhanced  to  meet  NAS-NAS  requirements,  includes  in  its 
basic  design  features  more  compatable  with  the  requirements  of  those  long-range  plans  for 
computer  system  modification. 

Conclusion  2:  If  NADIN  is  to  support  NAS-NAS  communications,  the  NADIN 

architecture  should  be  enhanced  so  as  to  provide  virtual  circuits  and  alternate  routing 
capabilities  based  on  packet-switching  technology. 

This  approach,  although  involving  more  modifications  and  greater  cost  than  the  other 
enhancements  to  NADIN  considered,  provides  greater  benefits,  not  just  with  respect  to  the 
NAS-NAS  service,  but  also  with  respect  to  longer  range  plans  for  computer  system 
modifiction  and  NADIN  evolution. 
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Conclusion  3:  Enhancements  to  the  NADIN  architecture  to  incorporate  packet¬ 

switching  technology  should  reflect  a  broader  range  of  requirements  than  just  those 
associated  with  the  NAS-NAS  service. 

The  suggested  enhancements  to  the  NADIN  architecture  will  facilitate  the  support  of 
a  number  of  FAA  communications  requirements  in  addition  to  the  NAS-NAS  service. 
Greater  efficiency  would  thus  be  achieved  by  implementing  an  integrated  enhancements 
package,  optimized  to  support  as  many  of  those  requirements  as  practical.  Since  the 
NAS-NAS  Network  currently  performs  in  a  completely  satisfactory  manner,  reasonable 
delays  to  develop  and  implement  such  an  integrated  enhancements  package  can  be  tolerated. 

1.2  PURPOSE  AND  SCOPE 


Under  FAA  Contract  DOT-FA79WA-4355,  Network  Analysis  Corporation  (NAC)  is 
investigating  the  feasibility  and  technical  approaches  for  enhancing  NADIN  to  incorporate  a 
variety  of  communications  services  not  included  as  part  of  the  initial  implementation. 
Results  of  earlier  efforts  under  that  contract  have  already  been  reflected  in  the  specifica¬ 
tions  for  the  first  enhancements  to  NADIN  (NADIN  IA). 

Task  2  of  the  contract  addressed  the  Computer  B  (NAS-NAS)  service.  It  determined 
the  most  cost/beneficial  approach  to  the  support  of  NAS-NAS  communications,  considering 
the  current  Computer  B  (NAS-NAS)  Network  and  various  enhancements  to  NADIN  IA.  This 
report  documents  that  study  and  its  results. 

In  order  to  establish  a  baseline  of  costs  and  benefits  that  would  result  from  including 
various  services  within  NADIN,  each  service  is  being  considered  separately  during  the  initial 
phases  of  the  contract.  Thus  this  task  (Task  2)  considered  the  possible  enhancement  of 
NADIN  IA  to  incorporate  the  NAS-NAS  service  with  minimal  regard  to  other  possible 
service  additions.  Further,  it  considers  only  subjectively  the  impact  of  the  ATC  Computer 
Replacement  Program  (CRP)  and  the  Advanced  Enroute  Automation  (AERA)  Program.  The 
results  of  Task  2  and  other  tasks  related  to  individual  communications  services  will, 
however,  serve  as  major  inputs  for  three  broader  tasks  under  the  contract: 

•  Tasks  12  and  14,  which  address  communications  support  for  the  Computer 
Replacement  Program,  and 

•  Task  13,  which  addresses  the  integration  of  the  individual  service  requirements 
and  proposed  enhancements. 
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1.3  BACKGROUND 


The  National  Airspace  System  (NAS)  requires  an  intercenter  computer  communications 
subsystem  for  the  fast,  accurate  and  reliable  exchange  of  flight  plans  and  track  data.  This 
communications  service  is  currently  provided  by  the  Computer  B  (NAS-NAS)  Network.  That 
network  is  a  collection  of  point-to-point  circuits  between  the  NAS  9020  computer  complexes 
located  at  neighboring  Air  Route  Traffic  Control  Centers  (ARTCCs). 

The  NAS-NAS  Network  performs  in  a  highly  acceptable  manner,  at  a  cost  that  is  high 
but  not  unreasonable.  Although  this  network  should  be  able  to  provide  high  quality  service 
indefinitely,  broader  FAA  concerns  suggest  that  it  might  be  beneficial  to  provide  the 
NAS-NAS  service  through  a  more  flexible,  common  network,  such  as  NADIN. 

1.3.1  NAS-NAS  Network  Limitations 


As  suggestd  above,  there  are  no  limitations  associated  with  the  performance  of  the 
NAS-NAS  Network.  The  NAS-NAS  service  does,  however,  impact  on  other  areas  of  FAA 
interest.  These  broader  concerns  reveal  limitations  in  terms  of  cost,  NAS  9020  communica¬ 
tions  overhead  and  interconnection  flexibility. 

1.  Cost:  The  major  concern  of  FAA  is  air  safety.  Cost  must  thus  be  a  lessor 
concern  when  considering  enhancements  to  the  Air  Traffic  Control  (ATC) 
System.  Nevertheless,  cost  efficiency  is  always  desirable,  especially  in  light  of 
the  current  tight  government  budget  and  the  continuing  cost  increases  for 
communications  facilities. 

The  current  NAS-NAS  Network  employs  dedicated,  redundant  communications 
links,  with  capacity  far  in  excess  of  that  required,  even  considering  projected  air 
traffic  growth  to  the  end  of  the  decade.  The  annual  cost  of  this  service  is 
currently  about  $500,000.  Significant  savings  should  be  possible,  without 
significant  service  degradation,  through  the  sharing  of  communications 
resources. 

2.  NAS  9020  Communications  Overhead:  The  NAS-NAS  Network  requires  four 
NAS  9020  adaptor  ports  at  each  end  of  a  link  between  two  ARTCCs.  As  a  result 
up  to  28  such  ports  are  required  at  one  NAS  9020  complex  just  for  the  NAS-NAS 
service.  In  addition,  the  NAS-NAS  Network  requires  that  the  NAS  9020 


computers  perform  essentially  all  associated  communications  functions, 
functions  that  can  generally  be  performed  more  efficiently  by  specialized 
communications  equipment. 

These  requirements  on  9020  resources  are  not  excessive,  even  when  considered  in 
combination  with  similar  requirements  for  other  communications  services 
terminating  at  the  9020  computer.  However,  the  projected  growth  in  air  traffic 
together  with  the  associated  need  to  automate  more  ATC  functions  would  strain 
the  capacity  and  capabilities  of  the  9020  computers  in  the  next  decade.  In  light 
of  this,  FAA  has  initiated  the  ATC  Computer  Replacement  Program,  directed 
toward  the  replacement  of  the  9020s  starting  about  1988. 

Possible  reduction  of  NAS-NAS  communications  requirements  on  the  9020  would 
be  beneficial  from  two  aspects.  First,  any  reduction  in  such  requirements  would 
increase  the  capacity  of  the  9020  for  new  functions  prior  to  computer 
replacement.  Second,  at  the  time  of  computer  replacement,  switch-over  and 
testing  would  be  greatly  facilitated  if  the  number  of  individual  interfaces  to  the 
computers  were  reduced. 

Incorporation  of  the  NAS-NAS  service  into  a  common  network  such  as  NADIN 
could  significantly  reduce  the  number  of  interfaces  required.  The  potential 
would  also  exist  to  reduce  the  communications  functions  performed  by  the  9020. 
Utilizing  this  latter  potential  would  require  major  modifications  to  the  NAS  9020 
software  and  should  be  avoided  unless  computer  capacity  becomes  strained  prior 
to  replacement  of  the  NAS  9020s.  Use  of  a  common  network  for  NAS-NAS 
communications  could  thus  serve  as  a  near-term  hedge  and  a  longer  range 
transition  facilitator. 

Interconnection  Flexibility:  Although  the  NAS-NAS  Network  has  a  highly 
connected  topology,  direct  communications  is  only  provided  between  designated 
ARTCCs,  generally  those  that  are  adjacent.  Any  use  of  the  network  for  indirect 
routing  of  messages  requires  the  inclusion  of  switching  functions  in  the  9020 
software  and  places  a  greater  processing  load  on  the  9020  computer.  This 
approach  has  been  employed  at  selected  ARTCCs  to  relay  flight  data  from  more 
remote  ARTCCs  to  the  Jacksonville  computer  complex,  to  aid  in  flow  control. 


NAS-NAS  communications  between  centers  that  are  not  directly  linked  by  the 
current  network,  although  not  currently  required,  will  be  required  by  the  end  of 
the  decade.  Following  replacement  of  the  NAS  9020s,  a  major  program  (AERA) 
to  increase  automation  of  enroute  ATC  functions  is  to  be  implemented.  The 
degree  of  automation  anticipated  makes  it  essential  that  there  be  no  significant 
break  in  automated  functions,  even  if  an  entire  center  is  lost  (e.g.,  as  a  result  of 
an  earthquake).  Various  concepts  are  being  studied  by  FAA  to  provide  for  such 
contingencies.  These  generally  involve  the  use  of  the  ATC  computers  at  one  or 
more  neighboring  centers  to  back  up  an  inoperative  ATC  computer.  Each  ATC 
computer  must  thus  be  able  to  exchange  NAS-NAS  messages  with  the  same 
computers  as  the  one(s)  it  is  designated  to  back  up. 

In  order  to  provide  such  flexibility  in  the  NAS-NAS  Network,  each  ATC 
computer  would  have  to  act  as  a  message  switch  or  there  would  have  to  be  a 
major  increase  in  the  number  and  miles  of  dedicated  NAS-NAS  links.  A  common 
network  would  not  be  so  limited.  NADIN,  with  its  centralized  switches  and  the 
ability  of  one  switch  to  back  up  the  other,  already  provides  for  inter¬ 
communications  between  all  ATC  computers.  A  less  centralized  topology  would, 
however,  serve  this  function  more  effectively. 

1.3.2  NADIN  Limitations 


Use  of  NADIN  to  support  NAS-NAS  communications  can  overcome  the  above 
limitations  of  the  NAS-NAS  Network.  Initial  NADIN  and  its  first  enhancement  (NADIN  I  A), 
although  designed  to  provide  high  level  performance,  have  limitations  with  respect  to 
supporting  the  NAS-NAS  service.  These  relate  to  network  delays  and  back-up  service. 

1.  Network  Delays.  The  point-to-point,  dedicated  links  of  the  NAS-NAS  Network 
result  in  almost  no  network  delay.  Use  of  NADIN,  on  the  other  hand,  would 
require  NAS-NAS  traffic  to  contend  with  other  message  traffic  for  use  of  the 
links.  Additional  delays  are  introduced  by  processing  at  the  concentrators  and 
switches.  Although  the  specifications  for  initial  NADIN  and  NADIN  IA  call  for 
average  end-to-end  delays  of  less  than  two  seconds,  this  is  not  felt  to  be 
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satisfactory  for  NAS-NAS  traffic.  Further  enhancements  to  NADIN,  such  as 
increasing  link  capacities,  providing  dedicated  virtual  channels  and/or  providing 
special  priorities  for  NAS-NAS  messages,  could  reduce  the  network  delays. 

2.  Back-Up  Service.  The  current  NAS-NAS  Network  provides  redundant,  full- 
duplex  lines  for  each  network  link.  Thus,  if  one  line  is  lost,  the  other  can  provide 
the  complete,  undegraded  service.  Initial  NADIN  and  NADIN  IA  provide  a  dial 
back-up  system  for  use  in  the  event  of  primary  line  outages.  This  back-up 
system,  which  uses  the  nationwide,  commercial  circuit-switched  network,  does 
not  provide  the  same  quality  of  service  as  that  of  the  NAS-NAS  Network. 
Specifically: 

•  it  requires  longer  to  reestablish  connections  after  a  line  outage;  and 

•  it  does  not  provide  link  qualities  equivalent  to  those  of  the  primary 
leased  lines. 

1.4  STUDY  APPROACH 


In  order  to  determine  the  most  cost/beneficial  approach  for  the  support  of  NAS-NAS 
communications,  a  four  step  analysis  methodology  has  been  employed.  These  steps  are 
identified  below,  including  references  to  the  more  detailed  presentations  later  in  this  report. 

Step  1.  Identification  of  the  environment  and  requirements  associated  with 
NAS-NAS  communications  (Section  2). 

Step  2.  Identification  of  alternative  approaches  for  enhancing  NADIN  to  meet  the 
NAS-NAS  requirements  (Section  3,  with  additional  details  provided  in 
Appendices  A,  B  and  C). 

Step  3.  Analysis  of  the  individual  alternatives  (Section  4). 

Step  4.  Comparative  evaluation  of  the  various  alternatives  (Section  5). 
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SECTION  2 


COMMUNICATIONS  ENVIRONMENT  AND  REQUIREMENTS 


2.1  INTRODUCTION 


As  a  first  step  in  the  analysis  of  approaches  to  support  NAS-NAS  communications,  a 
requirements  profile  was  developed.  That  profile  has  three  major  components: 

Communications  Environment:  (Section  2.2)  -  This  section  presents  an  overview  of 
current  FAA  flight  data  communications,  emphasizing  the  NAS-NAS  Network.  A  brief 
discussion  of  NADIN  and  its  relationship  to  such  communications  is  also  included. 

Strategic  Requirements:  (Section  2.3)  -  This  section  identifies  the  qualitative 

requirements  that  would  apply  to  any  communications  utility  being  considered  to  serve 
the  NAS-NAS  functions.  These  requirements,  which  provide  scope  and  direction  to 
subsequent  analyses,  include  objectives,  policy  and  cost  analysis  procedures. 

Tactical  Requirements:  (Section  2.4)  -  This  section  identifies  the  quantitative 

requirements  that  would  apply  to  any  communications  utility  being  considered  to  serve 
the  NAS-NAS  functions.  These  requirements,  which  govern  the  development  of  design 
details,  include  connectivity,  capacity  and  performance. 

2.2  COMMUNICATIONS  ENVIRONMENT 

In  order  to  control  enroute  IFR  air  traffic,  FAA  operates  20  ARTCCs  within  the 
counterminious  U.S.  (CONUS).  These  centers  and  the  area  each  controls  are  indicated  in 
Figure  2-1.  Because  of  their  key  role  in  air  traffic  control,  these  centers  are  major  nodes  in 
a  variety  of  FAA  communications  networks  and,  in  particular,  have  been  selected  as 
communications  concentrator  locations  for  NADIN. 
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2.2.1  General  Flight  Data  Communications 

Effective  air  traffic  control  requires  that  timely  information  about  planned  and  active 
IFR  flights  be  made  available  to  FAA  controllers  at  the  centers  and  at  facilities  in  terminal 
areas  which  the  flights  use  or  overfly.  Flight  data  are  provided  to  the  centers  from  a 
number  of  sources.  These  include: 

•  flight  service  stations,  airline  offices,  military  base  operations  (BASOPS)  and 
non-U.S.  centers  and  stations,  which  provide  original  flight  plans  and  flight  plan 
amendments, 

•  terminal  areas,  which  provide  flight  plans  and  progress  data, 

•  radars,  which  provide  flight  position  and  identification  data,  and 

•  neighboring  ARTCCs,  which  provide  flight  plans  and  track  data  for  flights 
crossing  center  boundaries. 

The  high  volume  of  air  traffic  and  the  resulting  high  volume  of  flight  data  made  it 
mandatory  that  the  associated  data  processing  functions  be  automated.  For  this  purpose, 
FAA  has  installed  a  computer  complex  at  each  ARTCC.  These  complexes,  using  NAS  9020 
computers  (also  referred  to  as  the  NAS  En  Route  Stage  A  computers),  process  all  flight 
related  data  received  by  the  center  and,  at  the  appropriate  time,  pass  pertinent  data  on  to: 

•  enroute  controllers  at  the  ARTCCs, 

•  terminal  area  controllers  and  computers, 

•  the  central  flow  control  computer,  and 

•  neighboring  center  computers. 
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2.2.2  Current  Flight  Data  Networks 


The  NAS  9020  computers  receive  and  disseminate  flight  data  through  a  variety  of 
communications  networks  and  circuits  (Reference  1).  Many  of  these  circuits  are 
intra-center  (i.e.,  they  provide  enroute  controllers  and  other  center  personnel  access  to 
flight  data)  or  provide  direct  computer  input  from  remote  radars.  Of  greater  interest  for 
this  study  are  the  networks  and  circuits  connecting  the  NAS  9020s  with  facilities  outside  of 
the  center.  These  are  indicated  in  Figure  2-2  and  are  described  briefly  below. 

The  Area  B/Supplemental  B  Networks  connect  the  NAS  9020s  with  teletype  terminals 
at  flight  service  stations  and  non-U. S.  centers  and  stations.  These  networks  primarily 
provide  for  flight  plan  data  entry  to  the  computers.  Computer  outputs  over  these  networks 
primarily  include  displays  of  previously  entered  data  and  messages  related  to  input 
acceptance  or  rejection. 

The  Utility  B  Circuits  connect  the  NAS  9020  computers  to  teletype  terminals  at 
airline  offices  and  military  BASOPS  within  the  centers'  control  areas.  These  circuits  serve  a 
function  similar  to  the  Area  B/Supplemental  B  Networks. 

The  Center  B  Network  is  primarily  a  teletype-to-teletype  network  interconnecting  the 
ARTCCs  and  special  FAA  administrative  and  support  facilities.  The  NAS  9020s  are  linked 
to  this  network  to  permit  limited  message  transmission  to  the  Central  Flow  Control  Facility 
in  Washington,  D.C. 

The  FDEP  Circuits  interconnect  the  NAS  9020  computers  with  keyboards  and  flight 
strip  printers  at  towers  and  approach  control  facilities  in  terminal  areas.  These  circuits 
primariy  provide  for  the  exchange  of  flight  plans  and  progress  data  between  the  terminal 
area  controllers  and  the  NAS  9020. 

The  Computer  B  (NAS-ARTS)  Network  interconnects  “ach  NAS  9020  computer 
complex  with  Automated  Radar  Terminal  System  (ARTS)  computers  located  in  the  busier 
terminal  areas.  This  network  provides  for  the  automatic  exhange  of  flight  plan  and  track 
data  and  facilitates  the  handoff  of  flights  that  cross  terminal  area  boundaries. 

The  Computer  B  (NAS-NAS)  Network  interconnects  the  NAS  9020  computers  at 
(generally)  adjacent  ARTCCs.  This  network  provides  for  the  automatic  exchange  of  flight 
plan  and  track  data  for  flights  that  cross  center  boundaries  and  facilitates  the  handoff  of 
such  flights.  Portions  of  this  network  are  also  used  as  part  of  the  Automated  Flow  Control 
(AFC)  Store-and-Forward  Network,  discussed  below. 

The  AFC  Store-and-Forward  Network  connects  the  NAS  9020  computers  with  the 
Jacksonville  Computer  Complex  (JCC).  This  network  provides  for  the  transfer  of  flight 
plans  and  progress  data  (on  selected  flights)  from  the  ARTCCs  to  the  JCC.  It  provides 


direct  connections  between  the  JCC  and  the  NAS  9020  computers  at  five  ARTCCs,  called 
Forwarding  Centers.  Messages  from  other  ARTCCs  are  routed  through  the  Forwarding 
Centers  on  a  store-and-forward  basis  using  specific  NAS-NAS  Network  links. 


2.2.3  The  NAS-NAS  Network 

The  current  NAS-NAS  Network  is  composed  of  90  independent  point-to-point 
communications  links.  The  nodes  of  the  network  are  the  NAS  9020  computers  at  the  20 
CONUS  ARTCCs.  The  interconnectivity  between  these  nodes  is  shown  in  Figure  2-3. 

Each  connection  shown  in  Figure  2-3  actually  represents  two  distinct  communications 
links.  This  is  illustrated  in  Figure  2-4.  Between  every  pair  of  interconnected  9020s  there 
are  two  2400  bit  per  second  (b/s)  full  duplex  lines,  each  primarily  responsible  for  carrying 
message  traffic  in  one  direction.  Should  one  of  the  two  lines  fail,  the  full  duplex  capability 
of  the  other  is  used  to  handle  all  the  traffic.  Should  both  lines  fail,  messages  are 
automatically  routed  to  a  printer  at  the  sending  center.  Supervisory  personnel  are  then 
responsible  for  transmitting  the  messages  to  the  destination  center  by  teletype  or  voice 
communications. 

The  lines  are  interfaced  with  the  9020s  through  modems,  which  are  directly  connected 
to  Interfacility  Input  (INTI)  and  Interfacility  Output  (INTO)  Adaptors  in  the  Peripheral 
Adaptor  Modules  (PAM)  of  the  9020s.  Although  not  shown  in  Figure  2-4,  each  modem  is 
connected  to  two  INTI  and  two  INTO  adaptors  on  separate  PAMs,  in  order  to  insure  high 
availability.  (Detailed  discussion  of  the  interface  is  contained  in  References  2  and  3).  Data 
transferred  through  the  INTI/INTO  adaptors  must  use  9  bit  (8  data  bits  plus  1  parity  bit) 
characters.  The  bits  are  transmitted  serially. 

The  NAS-NAS  Network  is  used  to  transmit  13  types  of  messages  (ignoring  AFC  store- 
and-forward  messages)  between  the  9020s.  These  are  discussed  briefly  below,  in  terms  of 
four  message  categories.  (Detailed  discussion  of  each  message  type  is  provided  in 
References  4  and  5.) 

2. 2. 3.1  Flight-Data  Messages 

Prior  to  the  time  that  an  IFR  flight  is  expected  to  cross  the  boundary  between  two 
ARTCCs,  the  currently  controlling  center  (sending  center)  must  transmit  the  associated 
flight  plan  data  to  the  center  that  is  to  have  control  following  the  boundary  crossing 
(receiving  center).  Such  data  is  transmitted  through  four  types  of  messages: 


NETWORK  PHYSICAL  CONNECTIONS 


Flight  Plans  (FP)  -  the  current  flight  plan  as  stored  by  the  sending  center, 


Amendment  Messages  (AM)  -  updates  to  a  flight  plan  previously  transmitted, 

Remove  Strip  Messages  (RS)  -  instructions  to  the  receiving  center  to  delete  all 
previously  transmitted  flight  plan  data  for  specific  flights,  and 

Hold  Messages  (HM)  -  notifications  to  the  receiving  center  that  flights  for  which  data 
were  previously  transmitted  are  in  an  indefinite  hold  status. 

2. 2. 3. 2  Track-Data  Messages 

As  boundary  crossing  becomes  imminent,  flights  will  be  handed  off  through  a  series  of 
track-data  messages.  Three  types  of  messages  are  used: 

Initiate  Transfer  Messages  (TI)  -  notification  from  the  sending  to  receiving  center 
that  the  hand-off  process  is  beginning, 

Track  Update  Messages  (TU)  -  updates  of  flight  velocity  and  coordinates  for  flights  in 
hand-off  status,  transmitted  from  the  sending  to  receiving  center,  and 

Accept  Transfer  Messages  (TA)  -  notification  to  the  sending  center  that  the  receiving 
center  has  accepted  a  handoff,  or  notification  to  the  receiving  center  that  the  sending 
center  is  taking  the  flight  out  of  hand-off  status. 

2.2.3.3  Response  Messages 

Whenever  a  NAS  9020  receives  a  flight-data  or  track-data  message,  other  than  a  TU, 
it  automatically  responds  with  one  of  three  messages: 

Accept  Message  (DA)  -  indicator  that  a  valid  message  with  no  errors  was  received, 

Request  Retransmission  Message  (DX)  -  instruction  to  retransmit  a  message  that  was 
received  with  transmission  errors,  and 


Reject  Message  (DR)  -  notification  that  an  unacceptable  message  was  received. 


2. 2. 3. 4  Miscellaneous  Messages 


Other  messages  are  also  transmitted  infrequently  between  the  9020  computers.  These 
include: 

•  General  Information  Messages  (GI), 

•  Test  Messages  (TR),  and 

•  Center  Operational  Messages. 

2.2.4  NADIN 


NADIN  (Reference  6)  is  being  developed  as  a  common  data  communications  network  to 
integrate  many  of  the  currently  separate  FAA  communications  networks  and  to  facilitate 
the  addition  of  new  FAA  communications  services.  Figure  2-5  illustrates  the  basic  elements 
of  the  initial  NADIN  implementation. 

NADIN  concentrators  will  be  located  at  each  of  the  20  CONUS  ARTCCs  plus 
Anchorage,  Honolulu  and  San  Juan.  Each  concentrator  is  directly  connected  to  one  of  two 
NADIN  switches  (backup  connection  to  the  second  switch  is  also  provided).  The  switches 
and  concentrators  are  further  connected  to  a  variety  of  computers  and  data  terminals  which 
constitute  the  origins  and  destinations  of  the  messages  handled.  In  particular,  each  NADIN 
concentrator  will  be  directly  connected  to  the  collocated  9020  complex. 

Initial  implementation  of  NADIN  (expected  by  early  1983)  will  direct  all  messages  to  a 
NADIN  switch.  The  switch  will  administratively  process  the  messages  and  route  them  to  the 
desired  destinations.  Among  the  services  to  be  included  as  part  of  the  initial  implementa¬ 
tion  are  Area  B/Supplemental  B,  Utility  B  and  Center  B.  The  FDEP  service,  as  upgraded 
under  the  FDIO  program,  and  the  AFC  Store-and-Forward  service  are  also  expected  to  be 
incorporated  at  the  time  of  or  shortly  after  initial  implementation.  Thus,  the  external 
NAS  9020  communications  by  late  1983  should  appear  as  shown  in  Figure  2-6. 

A  variety  of  enhancements  are  being  considered  for  NADIN.  Thus,  to  more  efficiently 
accommodate  the  FDEP/FDIO  service,  local  switching  at  the  NADIN  concentrators 
(Reference  7)  is  to  be  provided  as  part  of  the  first  NADIN  enhancement  (NADIN  IA).  This 
feature  will  have  the  concentrator  (rather  than  the  NADIN  switch)  route  pertinent  classes 
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OODO 


SWITHEJ  -  2;  E-ATLANTA,  W-SALT  LAKE  CITY 

CONCENTRATORS  -  23;  ONE  AT  EACH  ARTCC  AND  ANCHORAGE,  HONOLULU,  AND 
SAN  JUAN 

TERMINALS  -  UP  TO  ABOUT  50  PER  CONCENTRATOR  THROUGHOUT  EACH  ARTCC  AREA, 
PLUS  SOME  AT  SWITCHES.  SOME  ON  DEDICATED  CIRCUITS,  MOST  ON  MULTIPOINT 

EXTERNAL  SYSTEMS  AND  NETWORKS,  E.G. ,  INTERNATIONAL  AFTN,  WMSC 


FIGURE  2-5:  NADIN  I  SCHEMATIC 
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FIGURE  2-6:  EXTERNAL  COMPUTER  COMMUNICATIONS  (NAPIN  1983) 


of  messages  whose  origins  and  destinations  are  both  within  the  area  controlled  by  the 
associated  ARTCC  (this  is  the  case  for  FDEP  messages).  Another  possible  enhancement 
involves  direct  connections  between  selected  concentrators,  thereby  providing  alternate 
routing  capabilities.  This  feature  would  appear  to  offer  benefits  if  the  NAS-NAS  service 
were  incorporated  ii  to  NADIN. 

2.3  STRATEGIC  REQUIREMENTS 

A  communications  utility  must  meet  the  folowing  strategic  requirements  in  order  to 
be  considered  an  acceptable  alternative  for  handling  the  NAS-NAS  traffic. 

2.3.1  Objectives 

The  NAS-NAS  utility  must  satisfactorily  perform  the  current  functions  of  the 
NAS-NAS  Network  (other  than  those  associated  with  the  Network's  interim  role  as  part  of 
the  AFC  Store-and-Forward  Network).  Since  the  current  NAS-NAS  Network  is  satisfactory 
and  since  the  NAS  9020  computer  system  is  due  to  be  replaced  around  1990,  a  utility  to 
replace  the  current  network  must  perform  the  NAS-NAS  functions  at  a  total  cost  no  greater 
than  the  current  network,  and  with  minimal  changes  to  the  computer  system. 

The  requirement  for  minimal  change  leads  to  many  of  the  tactical  requirements 
presented  later.  At  the  strategic  level,  this  requirement  implies: 

•  the  NAS-NAS  utility  must  require  no  changes  to  the  NAS  9020  software,  other 
than  minor  modifications  to  accommodate  a  new  interface,  and 

•  the  utility  must  be  transparent  to  enroute  controllers,  thus  avoiding  the  need  for 
special  training  (i.e.,  it  must  introduce  no  new  or  altered  controller  activities, 
nor  modify  the  displays  received  by  the  controllers). 

2.3.2  Policy 

The  utility  must  be  consistent  with  FAA  Order  1830.2  (Reference  8).  That  order 
identifies  sets  of  standards  related  to  communications  codes,  signalling  rates,  transmission 
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modes,  bit  sequencing,  character  structure,  link  control  procedures,  message  transfer  and 
electrical  and  physical  interfaces  to  be  implemented  as  part  of  new  or  upgraded  FAA  data 
communications  systems. 

2.3.3  Cost  Estimation 


As  indicated  earlier,  the  NAS-NAS  utility  must  cost  no  more  than  the  current 
NAS-NAS  Network.  Cost  comparisons  must  reflect  the  following,  in  addition  to  standard 
considerations. 

•  Comparisons  must  be  based  on  life-cycle  costs;  i.e.,  they  must  appropriately 
combine  one-time  and  recurring  costs. 

•  Comparisons  must  be  based  on  differences  in  cost  to  the  total  FAA  program. 
Thus,  since  NADIN  concentrators  and  switches  will  be  purchased  regardless  of 
NAS-NAS  utility  selected,  their  costs  need  not  be  considered.  Similarly,  when  a 
utility  based  on  NADIN  is  considered,  only  the  incremental  costs  of  enhancing 
NADIN  must  be  included.  For  such  considerations  it  will  be  assumed  that 
NADIN  IA  (Reference  9)  is  to  be  funded  and  implemented  by  1983,  regardless  of 
any  decision  concerning  the  NAS-NAS  utility. 

2.4  TACTICAL  REQUIREMENTS 

A  communications  utility  must  meet  the  following  tactical  requirements  in  order  to  be 
considered  an  acceptable  alternative  for  handling  the  NAS-NAS  traffic. 

2.4.1  System  Configuration 

The  nodes  of  the  NAS-NAS  communications  service  are  the  NAS  9020  computer 
complexes  at  the  20  CONUS  ARTCCs.  In  general,  each  center  must  have  connectivity  with 
every  other  center  sharing  a  common  boundary.  In  addition,  since  some  flights  using 
overwater  routes  bypass  intervening  ARTCC  air  space,  connectivity  is  required  between: 
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•  New  York  and  Jacksonville 

•  New  York  and  Miami 

•  Miami  and  Houston 

No  connectivity  is  required  between  Houston  and  Albuquerque,  since  no  air  lanes  cross  the 
short  common  boundary  between  those  centers. 

The  required  connectivity  is  indicated  by  the  current  two-way  Computer  B  (NAS- NAS) 
Network  links,  shown  earlier  in  Figure  2-3.  The  direct  connectivity  provided  by  the  current 
network  is,  however,  not  necessarily  required. 

2.4.2  Message  Traffic 

The  NAS-NAS  message  traffic  that  must  be  handled  by  the  utility  is  the  current 
NAS-NAS  traffic  (ignoring  AFC  store-and-forward  traffic)  and  its  projections  to  CY  1988 
(the  year  the  NAS  9020  replacement  is  to  begin).  The  best  "current"  message  traffic  data 
available  are  those  developed  as  part  of  the  1978  study  of  the  impact  of  AFC  store-and- 
forward  traffic  on  the  NAS-NAS  Network  (Reference  10).  Those  data  were  obtained  from 
detailed  analysis  of  System  Analysis  Recording  (SAR)  tapes  provided  from  all  20  ARTCCs. 
The  ARTCCs  were  requested  by  letter  (Reference  11),  dated  December  23,  1975,  to  provide 
tapes  "of  at  least  20  minutes  duration  selected  from  each  ARTCC's  peak  traffic  hour  for  any 
convenient  week  since  November  15,  1975.” 

The  1976  study  identified  eight  message  types  that  constituted  over  99  percent  of  the 
NAS-NAS  peak-period  message  traffic.  These  are: 


TI  - 

initiate  transfer 

TU  - 

track  update 

TA  - 

accept  transfer 

FP  - 

flight  plan 

AM  - 

amendment  messages 

RS  - 

remove  strip 

DA  - 

data  accept 

DR  - 

data  reject 
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The  only  change  anticipated  in  the  message  traffic  for  the  1983-88  time  frame  is  the  traffic 
volume.  The  message  types,  their  relative  frequencies  and  their  lengths  are  expected  to 
remain  unchanged. 

2.4.2. 1  Message  Lengths 

Analysis  of  the  SAR  tapes  for  the  1976  study  produced  the  NAS-NAS  message  length 
data  shown  in  Table  2-1  These  data  require  no  adjustment  for  use  in  this  study. 

2.4.2.2  Message  Traffic  Volumes 

Analysis  of  the  SAR  tapes  for  the  1976  study  produced  the  NAS-NAS  message  traffic 
volumes  (in  messages  per  hour)  for  individual  links  shown  in  Table  2-2.  As  indicated  earlier, 
the  specific  nodes  and  the  interconnectivity  requirements  are  not  expected  to  change  for 
the  1983-88  time  frame.  Only  the  traffic  volumes  shown  are  expected  to  change.  These 
should  grow  in  proportion  to  the  growth  in  IFR  air  traffic  that  crosses  center  boundaries. 

An  estimate  of  the  growth  rate  has  been  obtained  from  FAA  forecasts  of  IFR  aircraft 
handled  by  the  individual  centers  (Reference  12).  Selected  data  from  that  source  are  shown 
in  Table  2-3.  Implied  growth  factors,  relative  to  the  1976  data  are  shown  in  Table  2-4. 

In  order  to  obtain  a  conservative  estimate  of  message  traffic  growth,  the  maximum 
growth  factors  (1.8  for  1983,  2.2  for  1988)  have  been  used.  The  results  of  applying  these 
factors  to  the  1976  traffic  volumes  are  shown  in  Table  2-5  (for  1983)  and  2-6  (for  1988). 

2.4.3  Transmission  Delays 

All  flight-data  and  track-data  messages  must  be  transmitted  and  (except  for  TU 
messages)  responded  to  without  undue  delay.  Internal  NAS  9020  delays  in  responding  to  such 
messages  must  average  no  more  than  2  secoinds,  and  must  be  less  than  4  seconds,  90  percent 
of  the  time  (Reference  13).  Delays  due  to  message  queueing  and  actual  (one-way  trans¬ 
mission  of  the  data  and  response  messages  must  average  no  more  than  1  second,  and  must  be 
less  than  2  seconds  90  percent  of  the  time.  These  requirements  are  summarized  in 
Table  2-7. 
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Message 

Type 

Relative 

Frequency 

Message  Lengths  (characters) 

Coeff. 
of  Var. 

Average 

Maximum 

Minimum 

TI 

.082 

44.2 

49 

38 

.10 

TU 

.367 

33.8 

88 

28 

.25 

TA 

.077 

25.4 

30 

22 

.08 

FP 

.092 

79.1 

372 

52 

.34 

AM 

.062 

55.8 

254 

29 

.45 

RS 

.002 

26.5 

30 

25 

.09 

DA 

.310 

28.1 

36 

23 

.24 

DR 

.007 

23.9 

32 

19 

.56 

ALL 

1.000 

37.7 

372 

19 

.54 

Notes: 

Coefficient  of  Variation  =  Sample  Standard  Deviation/Average  Length. 
Message  Length  includes  all  current  overhead  characters. 


Source:  FAA-RD-76,  Automated  Flow  Control  Interim  Communications, 
August,  1976. 
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IFR  AIRCRAFT  HANDLED  (thousands) 


Center  1976  (Aet.)  1983  (Est.)  1988  (Est.) 


Albuquerque 

845 

1,183 

1,384 

Atlanta 

1,400 

1,989 

2,365 

Boston 

912 

1,228 

1,456 

Chicago 

1,851 

2,643 

3,276 

Cleveland 

1,652 

2,524 

3,155 

Denver 

722 

1,149 

1,380 

Fort  Worth 

1,323 

1,984 

2,459 

Houston 

1,172 

1,842 

2,272 

Indianapolis 

1,336 

2,006 

2,484 

Jacksonville 

1,105 

1,610 

1,836 

Kansas  City 

1,080 

1,656 

1,966 

Los  Angeles 

1,091 

1,624 

1,868 

Memphis 

1,151 

1,732 

2,115 

Miami 

1,039 

1,686 

1,998 

Minneapolis 

1,003 

1,600 

1,970 

New  York 

1,499 

2,180 

2,578 

Oakland 

952 

1,384 

1,645 

Salt  Lake  City 

462 

783 

923 

Seattle 

695 

1,234 

1,540 

Washington 

1,396 

1,995 

2.434 

TOTAL 

22,686 

34,032 

41,104 

Source:  FA  A-  AVP-79-1,  IFR  Aircraft  Handled,  forecast  by  Air  Route  Traffic 
Control  Center,  Fiscal  Years  1979-1990,  April,  1979. 


TABLE  2-3:  ANNUAL  IFR  AIRCRAFT  HANDLED  BY  CENTER 
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GROWTH  FACTOR* 


1983 

1988 

20-Center  Average 

1.5 

1.8 

Maximum 

(Seattle) 

1.8 

2.2 

Minimum 

(Boston) 

1.3 

1.6 

Busiest  Center 
(Chicago) 

1.4 

1.8 

Least  Busy  Center 
(Salt  Lake  City) 

1.7 

2.0 

*Ratio  of  IFR  Aircraft  Handled  for  indicated 
year  to  IFR  Aircraft  Handled  in  1976. 


TABLE  2-4:  RELATIVE  GROWTH  OF  IFR  AIR  TRAFFIC 
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32  1 


ACTIVITY 

NAS-NAS  Message  Transmission 
(FP,  AM,  RS,  HM,  TI,  TO,  TA) 

NAS  9020  Response  Processing 

NAS-NAS  Response  Transmission 
(DA,  DX,  DR) 


TABLE  2-7:  ACCEPTABLE  DELAYS  FOR  NAS-NAS  TRAFFIC 


DELAY  TIMES  (seconds) 
MEAN  90  PERCENTILE 

1  2 

2  4 

1  2 
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2.4.4  Availability/Reliability 

The  NAS-NAS  service  must  be  operational  seven  days  a  week.  Between  any  two 
centers,  the  utility  must  be  operational  during  the  hours  when  both  centers  are  to  be 
operational.  This  will  be  a  maximum  of  24  hours  a  day. 

Utility  outages  cannot  be  completely  avoided.  The  importance  of  the  NAS-NAS 
message  traffic  thus  requires  a  back-up  service.  Currently,  this  is  provided  by  redundancy 
and  through  off-line  printing  of  messages  for  transmission  over  intercenter  teletype  or  voice 
circuits.  The  latter  type  operations  cannot  be  tolerated  too  frequently  or  for  too  long  a 
period.  The  NAS-NAS  utility  must  thus  meet  the  following  reliability  requirements: 

•  Mean  Time  Between  Failures  (MTBF)  -  greater  than  1000  operational  hours  (less 
frequently  than  once  per  month). 

•  Mean  Time  to  Repair,  Replace  or  Bypass  (MTTR)  -  15  minutes  or  less. 
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SECTION  3 


IDENTIFICATION  OF  ALTERNATIVES 


3.1  INTRODUCTION 


Five  alternatives  for  supporting  NAS-NAS  communications  have  been  analyzed.  The 
first,  Alternative  1,  is  the  current  NAS-NAS  Network.  Three  involve  the  enhancement  of 
NADIN  to  completely  take  over  the  NAS-NAS  service.  One  involves  the  combined  use  of 
the  current  NAS-NAS  Network  and  NADIN. 

The  four  alternatives  involving  NADIN  have  been  specifically  tailored  to  overcome  one 
or  more  of  the  limitations  identified  earlier.  Thus: 

•  Alternative  2,  Enhanced  NADIN  IA,  includes  increased  capacities  on  selected 
links  to  assure  acceptable  NAS-NAS  message  delays. 

•  Alternative  3,  Enhanced  NADIN  Architecture,  provides  for  increased 
connectivity  among  NADIN  nodes  and  packet  switching  among  those  nodes,  to 
reduce  network  delays  and  minimize  the  need  for  a  separate  back-up  system. 

•  Alternative  4,  NAS-NAS/NADIN  IA,  eliminates  the  redundant  NAS-NAS 
Network  lines,  using  NADIN  I A  as  a  back-up  in  the  event  of  line  outage,  thus 
reducing  the  NAS-NAS  Network  cost  and  facilitating  full  transition  to  NADIN  at 
a  later  time. 

•  Alternative  5,  Redundant  NADIN  IA,  is  essentially  Alternative  2,  with  one  extra 
(9,600  b/s)  line  on  each  backbone  link,  to  increase  availability  and  thus  decrease 
reliance  on  a  dial  back-up  system. 

One  of  the  major  considerations  in  defining  the  NADIN  alternatives  was  to  assure  that 
NAS-NAS  message  delay  constraints  would  be  met.  As  a  general  rule,  such  assurance  can  be 
achieved  by  providing  special  handling  for  NAS-NAS  messages,  e.g.: 
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•  Under  Alternative  2,  NAS-NAS  messages  could  be  assigned  higher  priorities  than 
other  ATC  messages,  thus  minimizing  the  queueing  delays  at  the  network  nodes; 
and 

•  under  Alternative  3,  permanent  virtual  circuits  could  be  established  for 
NAS-NAS  messages,  thus  reducing  node  processing  delays. 

Although  such  approaches  are  valid  and  should  be  investigated  further,  they  were  not 
used  in  the  detailed  analyses  of  this  study.  Rather,  acceptable  delays  were  assured  by 
increasing  the  capacity  of  selected  network  links.  This  approach  was  felt  to  be  most 
appropriate  at  this  time  for  the  following  reasons: 

1.  It  is  not  clear  that  any  class  of  ATC  messages  should  be  given  special  handling 
relative  to  other  classes  of  ATC  messages. 

2.  Providing  special  handling  for  NAS-NAS  messages  can  be  expected  to  increase 
the  network  delays  for  other  NADIN  traffic.  A  broader  study  would  be  required 
to  investigate  network  adjustments  needed  to  meet  the  delay  constraints  for  the 
other  traffic,  if  NAS-NAS  messages  were  given  special  treatment. 

3.  The  approach  used,  i.e.,  increasing  link  capacities,  represents  a  conservative 
approach,  both  in  terms  of  cost  and  technology. 

4.  Even  with  the  approach  used,  it  was  possible  to  demonstrate  the  feasibility  and 
cost-effectiveness  of  NADIN  support  for  NAS-NAS  communications. 

Each  of  the  five  alternatives  is  defined  and  described  in  the  subsections  below.  Each 
is  analyzed  separately  in  Section  4. 

3.2  ALTERNATIVE  1,  THE  CURRENT  NAS-NAS  NETWORK 

The  first  alternative  considered  for  the  support  of  NAS-NAS  requirements  is  the 
continued  use  of  the  current,  independent  NAS-NAS  Network.  That  network  has  been 
described  in  Section  2.  Of  particular  interest  for  this  analysis  are  the  following  features  of 
the  network  (see  Figure  3-1): 
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FIGURE  3-1:  TYPICAL  NAS-NAS  MESSAGE  PATHS,  ALTERNATIVE  1 


•  The  network  provides  a  direct,  redundant  connection  between  every  pair  of 
NAS-9020  computer  complexes  that  exchange  NAS-NAS  messages. 

•  Each  link  consists  of  two  full-duplex,  voice-grade  channels,  each  operating  at 
2,400  bits  per  second  (b/s). 

•  Normally,  each  of  the  two  channels  supports  transmissions  in  one  direction  only; 
in  the  event  of  a  channel  outage,  the  full-duplex  capability  of  the  remaining 
channel  is  used  to  support  two-way  transmissions. 

This  network  has  proven  to  be  highly  effective.  However,  because  of  the  direct, 
dedicated,  redundant  connections,  it  is  relatively  expensive. 

3.3  ALTERNATIVE  2,  ENHANCED  NADIN  IA 

The  second  alternative  considered  for  NAS-NAS  communications  support  is  the  use  of 
NADIN,  essentially  as  configured  under  the  Level  IA  implementation.  This  network  has  also 
been  described  in  Section  2.  Of  particular  interest  in  this  analysis  are  the  following  features 
(see  Figure  3-2): 

•  A  NADIN  concentrator  will  be  located  at  each  of  the  20  CONUS  ARTCCs, 
collocated  with  the  NAS  9020  computer  complexes. 

•  Using  this  alternative,  each  NAS-NAS  message  would  always  be  routed  through 
one  or  both  NADIN  switches,  located  at  the  Atlanta  and  Salt  Lake  City  ARTCCs. 

•  Using  this  alternative,  NAS-NAS  message  traffic  would  have  to  contend  with 
other  high-priority  ATC  traffic  for  use  of  the  network  backbone  links. 

•  Under  the  Level  IA  implementation,  NADIN  backbone  links  will  consist  of  one  or 
two  full-duplex,  voice-grade  channels,  each  operating  at  9,600  b/s;  the 
multiplicity  (and,  hence,  capacity)  of  these  links  can  be  increased  to  meet  added 
requirements. 
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FIGURE  3-2:  TYPICAL  NAS-NAS  MESSAGE  PATHS,  ALTERNATIVE  2 


Alternative  2  would  eliminate  the  need,  and  therefore  the  cost,  for  operating  and 
maintaining  the  current  NAS-NAS  Network.  Since  NADIN  1A  has  been  designed  for  a 
variety  of  users  and  will  include  interfaces  with  the  NAS  9020  computers,  the  cost  to 
implement  Alternative  2  should  be  relatively  small.  Specifically,  the  only  major  costs 
involved  would  be  costs  for  minor  modifications  to  the  9020  software  (to  adapt  NAS-NAS 
messages  to  the  NADIN  interface)  and  costs  for  increasing  link  capacities  to  insure  that  the 
NAS-NAS  delay  constraint  is  met. 

An  analysis  has  been  performed  (see  Appendix  A)  of  the  network  delays  that  would 
result  if  the  NAS-NAS  traffic  were  directly  added  to  NADIN  IA.  That  analysis  indicated 
that  the  capacities  would  have  to  be  increased  on  fifteen  of  the  NADIN  iA  backbone  links  in 
order  that  the  NAS-NAS  delay  constraint  be  met.  Table  3-1  identifies  the  specific  links 
involved. 

3.4  ALTERNATIVE  3,  ENHANCED  NADIN  ARCHITECTURE 

The  third  alternative  involves  a  significant  modification  to  NADIN.  All  NADIN 
concentrator  nodes  would  be  converted  into  combined  concentrator/packet-switeh  nodes. 
Most  of  the  message  processing  functions  would  remain  with  the  two  NADIN  IA  message 
switches. 

The  backbone  nodes  (packet  switches)  for  this  alternative  would  be  interconnected  so 
as  to  create  a  distributed  network  (see  Figure  3-3).  The  specific  links  and  link  capacities 
would  be  selected  so  that: 

•  network  delay  constraints  were  not  exceeded, 

•  each  pair  of  switches  would  be  (directly  or  indirectly)  connected  by  at  least  two 
non-overlapping  routes,  and 

•  network  costs  would  be  minimized. 

Under  Alternative  3  it  would  still  be  necessary  to  route  some  messages  (but  not 
NAS-NAS  messages)  through  the  message  switches  at  Atlanta  and  Salt  Lake  City.  These 
would  primarily  include  those  messages  that  require  recording  for  historical  purposes,  those 
associated  with  external  systems  and  those  that  are  generated  with  less  sophisticated 
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LINK 

NODES 

NUMBER  OF  9,600  B/S 

CHANNELS  ON  LINK 

NADIN  IA 

ENHANCED 
NADIN  IA 

Atlanta  (C)  > 

1 

2 

Boston 

1 

1 

Chicago 

1 

2 

Cleveland 

1 

2 

Indianapol is 

1 

2 

Jacksonvi lie 

>  Atlanta  (S) 

1 

2 

Memph i s 

1 

2 

Mi  ami 

1 

2 

Minneapolis 

1 

2 

New  York 

1 

2 

Washington 

1 

2 

Atlanta  (S) 

Salt  Lake  City  (S) 

2 

2 

*\ 

Albuquerque 

1 

1 

Denver 

1 

2 

Fort  Worth 

1 

2 

Houston 

s.  Salt  Lake  City  (S) 

1 

2 

Kansas  City 

1 

2 

Los  Angeles 

1 

1 

Oakland 

1 

1 

Salt  Lake  City  (C) 

1 

2 

Seattle  j 

1 

1 

TOTAL 

22 

37 

NOTES: 


1.  The  Atlanta  and  Salt  Lake  City  nodes  are  indicated  as  either 
being  concentrators  (C)  or  switches  (S). 

2.  Backbone  links  to  off-shore  centers  are  not  included. 


TABLE  3-1:  LINK  CAPACITY  MODIFICATIONS  UNDER  ALTERNATIVE  2 
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CONNECI  1(1NS 


FIGURE  3-3:  TYPICAL  NAS-NAS  MESSAGE  PATHS,  ALTERNATIVE  3 


terminal  equipment.  There  will  never  be  a  requirement  to  route  a  message  through  both 
switches. 

A  more  complete  discussion  of  this  concept  and  its  impact  on  the  NADIN  architecture 
are  presented  in  Appendix  B.  An  analysis  was  performed  to  determine  a  typical  topology  for 
such  a  network;  i.e.,  linkages  and  link  capacities.  The  analysis  is  presented  in  Appendix  C; 
the  optimal  topology  determined  is  indicated  in  Figure  3-4. 

3.5  ALTERNATIVE  4,  NAS-NAS/ NADIN  IA 

The  fourth  alternative  retains  the  basic  NAS-NAS  Network,  but  eliminates  the 
redundant  line  on  each  link.  This  cuts  the  cost  almost  in  half,  but  also  reduces  link 
reliability. 

To  provide  back-up  service  in  the  event  of  a  NAS-NAS  line  outage,  this  alternative 
includes  an  interface  with  NADIN  IA.  Since  NADIN  would  serve  the  NAS  -NAS  traffic  only 
sporadically,  there  need  be  no  enhancement  of  NADIN  IA  specifically  to  accommodate  such 
traffic.  As  a  result,  the  primary  NAS-NAS  service  under  this  alternative  would  be 
essentially  the  equivalent  to  that  under  the  current  NAS-NAS  Network.  The  back-up 
service,  although  an  improvement  over  the  manual  back-up  system  for  the  current  network, 
would  be  expected  to  be  used  more  often,  and  would  not  provide  as  good  service  as  the 
current  redundant  lines. 

3.6  ALTERNATIVE  5,  REDUNDANT  NADIN  IA 

A  major  difference  between  Alternative  2  and  the  other  three  alternatives  defined 
above  is  the  quality  of  the  back-up  service,  should  a  primary  line  be  lost.  Alternative  1 
includes  redundant  lines  for  such  contingencies;  Alternative  3  provides  alternate  routes; 
Alternative  4  uses  NADIN  I  A.  Should  a  primary  line  under  Alternative  2  be  lost,  back-up 
service  would  be  provided  by  a  dial-up,  circuit-switched  system. 

Alternative  5  attempts  to  overcome  this  limitation  by  including  all  the  enhancements 
to  NADIN  I A  as  are  included  under  Alternative  2  and  by  further  including  one  additional 
9600  b/s  line  on  each  backbone  link.  Thus  the  loss  of  any  one  line  will  result  in  no  service 
degradation. 


FIGURE  3-4:  OPTIMAL  ALTERNATIVE  3  CONF I GURAT I ON 


SECTION  4 


ANALYSIS  OF  ALTERNATIVES 


4.1  INTRODUCTION 


As  described  in  Section  3,  the  five  alternatives  considered  for  supporting  NAS-NAS 
communications  can  meet  all  NAS-NAS  requirements.  Selection  of  a  preferred  alternative 
must  thus  be  based  on  the  comparison  of  additional  features  each  provides  and  cost.  Review 
of  the  five  alternatives  reveals  four  major  areas  to  be  considered  in  such  a  comparison. 
These  are  cost,  throughput  performance,  back-up  service  and  long-range  potential.  Only  the 
first,  cost,  provides  for  a  strictly  quantitative  comparison. 

4.1.1  Cost 


The  methodology  and  parameters  used  to  determine  comparative  costs  for  the  five 
alternatives  are  presented  in  Appendix  D.  The  major  considerations  include: 

•  A  single  comparative  cost  is  determined  for  each  alternative;  this  is  the  ten-year 
life  cycle  cost. 

•  The  life  cycle  cost  is  calculated  in  terms  of  present  value  in  1983,  assuming  a 
ten  percent  net  annual  discount  rate. 

•  The  Multi-Schedule  Private  Line  (MPL)  tariffs  are  assumed  to  apply  for  the 
communications  links  under  all  five  alternatives. 

•  It  is  assumed  that  funds  required  to  implement  NADIN  IA  without  further 
enhancements  and  to  operate  it  for  ten  years  will  be  committed  regardless  of  the 
NAS-NAS  alternative  selected.  Thus,  only  incremental  enhancements  costs  are 
included. 
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4.1.2  Throughput  Performance 

One  facet  of  throughput  performance,  i.e.,  the  end-to-end  delays  under  projected  1988 
throughput  requirements,  is  actually  reflected  in  the  costs  determined  for  each  alternative. 
Thus,  links  are  added  and/or  link  capacities  increased,  as  needed,  to  meet  the  delay 
constraints.  The  cost  for  such  adjustments  are  included  in  the  life  cycle  cost  calculations. 

This  category  of  comparison  thus  reflects  primarily  the  ability  of  the  alternatives  to 
handle  temporary  surges  in  throughput  requirements.  Generally,  systems  with  more  excess 
capacity  or  with  means  of  avoiding  further  use  of  nearly  congested  links  would  rate  better 
under  this  area  of  comparison. 

4.1.3  Back-Up  Service 

Both  the  NAS-NAS  Network  and  NADIN  have  been  designed  to  provide  high 
availability/reliability.  There  are,  however,  major  differences  in  the  quality  of  service 
available  among  the  five  alternatives  should  a  primary  line  be  lost.  Further,  some,  through 
redundancy  or  alternate  routing,  include  a  back-up  capability  within  the  primary  service. 
This  category  of  comparison  thus  reflects  the  combination  of  the  quality  of  back-up  service 
and  the  likelihood  that  the  back-up  service  would  be  required. 

4.1.4  Long-Range  Potential 

Long-range  potential  is  used  here  to  refer  to  the  benefits  that  might  be  realized  from 
implementing  a  specific  NAS-NAS  alternative  relative  to  broader,  long-range  ATC 
objectives  and  requirements.  The  ability  to  handle  increasing  traffic  levels  is  actually 
reflected  under  throughput  performance,  and  therefore  is  specifically  excluded  from  this 
area  of  comparison. 

The  major  considerations  under  long-range  potential  are  thus  the  ability  of  each 
alternative  to  support  or  facilitate  major  long-range  ATC  programs.  These  primarily 
include: 

•  the  ATC  Computer  Replacement  Program  (CRP), 

•  the  Advanced  EnRoute  Automation  Program  (AERA),  and 
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•  Center  Back-Up,  which  is  associated  with,  but  basically  separate  from,  both  CRP 
and  AERA. 


4.2  ALTERNATIVE  1,  THE  NAS-NAS  NETWORK 

Since  the  NAS-NAS  Network  exists  and  is  operationally  satisfactory,  analysis  of 
Alternative  1  has  been  directed  primarily  to  the  establishment  of  a  basis  for  comparisons 
among  the  alternatives.  Of  specific  interest  are  the  expected  delays  under  projected  1988 
message  traffic  levels  and  the  cost  of  retaining  the  NAS-NAS  Network. 

4.2.1  Alternative  1  Throughput  Performance 

Under  Alternative  1  the  transmission  of  a  NAS-NAS  message  would  involve  use  of  only 
a  single  network  link.  Further,  only  NAS-NAS  traffic  and  associated  link  control  traffic 
would  be  transmitted  on  that  link.  As  a  result  the  greatest  network  delays  would  be 
encountered  on  the  channel  carrying  the  greatest  volume  of  NAS-NAS  traffic. 

The  data  in  Section  2  identifies  the  Miami-to-Jaeksonville  channel  as  the  busiest  in  the 
NAS-NAS  Network.  It  has  been  projected  that  in  1988  there  would  be  2,332  NAS-NAS 
messages  transmitted  over  that  channel  during  a  peak  hour,  with  each  message  averaging 
37.7  (9-bit)  characters.  This  projection  includes  all  bits,  characters  and  messages 
transmitted  as  overhead  on  the  channel. 

This  message  transmission  requirement  translates  into  a  gross  throughput  requirement 
(GT)  of: 

GT  =  2,332  x  37.7  x  9/3600 

=  220  b/s  during  the  peak  hour. 

The  average  message  transmission  time  (TF)  on  the  2400  b/s  channel  would  be: 

TF  =  37.7  x  9/2400  =  .141  seconds 
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The  average  queueing  delay  (TQ)  prior  to  transmission  of  a  message  would  be: 


TQ  -  TF  x  U/(l-U) 

where  U  -  the  link  utilization 

=  GT/2400 

=  220/2400  =  .092 

Thus:  TQ  =  .141  x  .092/. 908  =  .014  seconds 

The  queueing  delay  and  transmission  time  are  the  only  significant  "network"  delays 
encountered  under  Alternative  1.  Thus  the  average  network  delay  (TD)  on  the  busiest 
channel  would  be: 

TD  =  TF  +  TQ 

=  .141  +  .014  =  .16  seconds 

This  maximum  average  delay  is  well  within  the  one  second  delay  constraint  identified 
for  the  NAS-NAS  traffic.  This,  together  with  the  very  low  link  utilization  (.092),  represents 
a  very  high  level  of  throughput  performance. 

The  above  calculations  are  based  on  standard  communications  analysis  models.  They 
are  discussed  in  more  general  terms  as  part  of  the  Alternative  2  analysis  in  Appendix  A. 

4.2.2  Alternative  1  Costs 


Since  the  NAS-NAS  Network  exists  and  since  the  link  capacities  are  sufficient  for  the 
projected  1988  traffic,  the  only  costs  associated  with  Alternative  1  are  the  monthly  charges 
by  the  communications  carrier.  Under  the  MPL  tariffs  these  include: 

•  a  fixed  monthly  charge  per  channel  ($51.72), 

•  an  inter-exchange  mileage  charge  (IXC)  for  each  channel, 
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•  a  station  terminal  (drop)  charge  for  each  drop  on  a  channel  ($26.30),  and 

•  a  channel  conditioning  charge  for  each  drop  on  a  channel  ($15.50). 

The  1XC  for  one  channel  on  each  of  the  45  NAS-NAS  links  is  shown  in  Table  4-1.  Since 
each  link  has  two  channels  and  each  channel  requires  two  drops,  the  monthly  recurring  cost 
(RC)  would  be  determined  as  shown  below: 


Fixed  Charges 

:  45  x  2  x  $51.72 

=  $  4,655 

IXC 

:  2  x  $18,746 

=  37,492 

Drop  Charges 

:  45  x  2  x  2  x  $26.30 

=  4,734 

Conditioning  Charges 

:  45  x  2  x  2  x  $15.50 

=  2,790 

RC 

=  $49,671 

The  life-cycle  cost  used  in  comparing  the  alternatives  includes  all  one-time  costs  and 
the  present  value  (PV)  of  all  recurring  costs,  applicable  over  a  10  year  system  lifetime. 
Since  there  are  no  one-time  costs  for  Alternative  1,  the  life-cycle  cost  (LC)  would  be  (see 
Appendix  D): 

LC  =  PV  =  RC  x  (1-(1+Dfm)/D 
where  D  =  the  assumed  net  discount  rate 

=  .008  per  month  (0.1  per  year) 

m  =  system  lifetime 

=  120  months 


Thus:  LC  =  $49,671  x  77.0  =  $3.82  million 
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TABLE  4-1:  INTEREXCHANGE  MILEAGE  CHARGE  (IXC) 


PER  CHANNEL,  ALTERNATIVE  1  (Page  1  of  2) 


link  nodes 


distance 

(miles; 


:  xc 

!$/CHANNEL/“ONTn, 


4.2.3  Alternative  1  Back-Up  Service 


The  high  availability/reliability  of  the  current  NAS-NAS  Network  is  provided  through 
three  design  elements: 

•  point-to-point  connections  between  each  pair  of  centers  that  exchange  NAS-NAS 
messages, 

•  redundant  full-duplex  lines  and  interfaces  for  each  interconnection,  and 

•  a  manual  back-up  system,  should  both  lines  be  lost. 

The  first  two  elements  assure  high  availability  for  at  least  one  end-to-end  connection 
between  two  centers.  The  parallel  redundant  lines  are,  however,  more  susceptible  to 
simultaneous  outage  from  external  causes  (e.g.  storms)  than,  for  example,  a  network 
providing  alternative  routing.  The  last  design  element  represents  a  relatively  poor  quality 
back-up  service,  on  those  rare  occasions  when  it  is  needed. 

4.2.4  Alternative  1  Long-Range  Potential 

The  current  NAS-NAS  Network  offers  little  long-range  potential,  as  considered  for 
this  study.  The  multiple  interfaces  that  this  network  requires  at  each  center  tend  to  make 
the  computer  replacement  process  (e.g.,  switch-over  and  testing)  more  difficult.  Further, 
since  this  network  provides  communications  from  one  center  to  only  a  limited  number  of 
other  centers,  it  could  not  directly  support  Center  Back-Up  concepts. 


4.3  ALTERNATIVE  2,  ENHANCED  NADIN  IA 


It  has  been  assumed  for  this  study  that  the  Level  IA  implementation  of  NADIN  will  be 
completed  in  1983.  The  incorporation  of  the  NAS-NAS  service  into  NADIN  under 
Alternative  2  would  thus  primarily  require: 

•  modifying  NAS  9020  software  to  direct  NAS-NAS  messages  to  the  appropriate 
output  adaptor  and  to  include  information  required  by  NADIN  (e.g.,  message 
destination)  in  the  NAS-NAS  message,  and 
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•  making  the  necessary  modifications  to  insure  that  the  NAS-NAS  message  delay 
contraint  is  not  exceeded. 

4.3.1  Alternative  2  Throughput  Performance 

NADIN  specifications  (Reference  6)  require  that  average  peak-period  network  (end-to- 
end)  delays  for  random  message  frames  be  no  greater  than  two  seconds.  In  order  to  meet 
that  requirement  for  traffic  to  be  handled  under  the  Level  IA  implementation,  it  has  been 
further  specified  (Reference  9)  that: 

•  each  link  between  a  NADIN  switch  and  a  NADIN  concentrator  be  a  full-duplex, 
voice-grade  channel,  operating  at  9,600  b/s,  and 

•  the  link  between  the  two  NADIN  switches  consist  of  two  full-duplex,  voice-grade 
channels,  each  operating  at  9,600  b/s. 

The  delay  constraint  for  NAS-NAS  message  traffic  is  more  demanding;  i.e.,  the 
average  peak-period  network  delay  must  be  no  greater  than  one  second.  The  impact  of 
implementing  Alternative  2,  on  the  delays  for  both  NAS-NAS  traffic  and  NADIN  IA  traffic, 
has  been  analyzed.  That  analysis  (see  Appendix  A)  determined: 

1.  The  overall  throughput  performance  would  still  meet  the  NADIN  requirements. 

2.  By  1988,  sixty-three  percent  of  the  NAS-NAS  origin/destination  pairs  would 
experience  peak-period  message  delays  averaging  more  than  one  second,  if 
NADIN  IA  were  left  essentially  unchanged. 

3.  The  major  contributing  factor  to  the  excessive  delays  are  the  queueing  delays  on 
the  busier  switch-to-concentrator  legs  of  the  message  paths. 

Several  approaches  are  possible  for  reducing  such  delays.  As  suggested  earlier,  this 
study  considered  only  the  increasing  of  the  number  and/or  capacity  of  the  backbone  links. 
The  required  modifications  were  shown  in  Table  3-1.  Although  these  modifications  assure 
that  the  NAS-NAS  requirements  are  met,  the  throughput  performance  is  relatively  low, 
especially  on  those  links  retaining  only  a  single  9,600  b/s  line. 
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4.3.2  Alternative  2  Costs 


Alternative  2  involves  both  one-time  and  recurring  costs.  The  one-time  cost  items 
include  installation  charges  and  modem  purchases  associated  with  the  added  channels  and 
the  cost  of  modifying  the  9020  software  that  controls  the  preparation  and  output  of 
NAS-NAS  messages.  Installation  costs  associated  with  the  added  channels  would  apply  only 
to  13  of  the  15  added  channels.  This  results  from  the  fact  that  two  of  the  added  channels 
are  between  the  switch  and  concentrator  at  Atlanta  and  at  Salt  Lake  City.  Those  links  are 
essentially  internal  to  the  respective  ARTCCs  and  should  require  no  significant  commercial 
service.  It  is  assumed,  however,  that  modems  would  be  purchased  for  those  channels. 

From  Appendix  D,  the  pertinent  one-time  charges  would  be: 

•  a  station  installation  charge  per  drop  per  added  commercial  channel  ($57), 

•  a  channel  conditioning  equipment  installation  charge  per  drop  per  added 
commercial  channel  ($171), 

•  modem  cost  per  drop  per  added  channel  ($8,500),  and 

•  software  development  costs  ($150  per  instruction). 

It  is  estimated  that  approximately  400  instructions  would  be  required  to  modify  the 
software.  Thus  the  one-time  costs  (OC)  would  be  determined  as  shown  below: 


Modems  :  15  x 2 x $8500  =  $  255,000 

Station  Installation  :  13  x  2  x  $57  =  1,482 

Conditioning  Installation  :  13x2x$171  =  4,446 

Software  :  400  x  $150  =  60,000 


OC  =  $  320,928 


The  recurring  costs  for  Alternative  2  include  primarily  the  monthly  charges  associated 
with  the  13  additional  commercial  channels.  Table  4-2  shows  the  IXC  for  these  channels. 
(Note,  only  the  column  titled  Alternative  2  applies  here;  the  column  titled  NADIN  IA  is 
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LINK  NODES* 

— 

DISTANCE 

(MILES) 

IXC 

(S/MONTH) 

NADIN  IA 

ALTERNATIVE  2 

Altanta  (C) 

Atlanta  (S) 

0 

S  0 

S  0 

Boston 

951.2 

720.00 

0 

Chicago 

620.0 

491.50 

491.50 

Cleveland 

558.7 

449.10 

449.10 

Indi anapol i s 

454.2 

377.00 

377.00 

Jacksonvi  1  le 

232.3 

224.00 

224.00 

Memph  i  s 

351.1 

305.90 

305.90 

Miami 

581.4 

464.90 

464.90 

Minneapol i s 

911.5 

692.60 

692.60 

New  York 

802.1 

617.10 

617.10 

Washington 

545.4 

440.00 

440.00 

Atlanta  (S) 

Salt  Lake  City  (S) 

1,599.5 

2,010.90** 

0 

Albuquerque 

485.8 

398.90 

0 

Denver 

359.4 

311.70 

311.70 

Fort  Worth 

983.3 

742.20 

742.20 

Houston 

1,190.1 

833.50 

333.50 

Kansas  City 

914.9 

695.00 

695.00 

Los  Angeles 

589.7 

470.60 

0 

Oakland 

586.1 

468.10 

0 

Salt  Lake  City  (C) 

0 

0 

0 

Seattle 

_ J 

684.4 

_ 

535.90 

0 

TOTAL  IXC 

$11,248.90 

$6,644.50 

*  The  Atlanta  and  Salt  Lake  City  nodes  are  distinguished  as  being 
either  concentrators  (C)  or  switches  (S). 


**  Value  reflects  two  9,600  b/s  channels. 


TABLE  4-2:  INTEREXCHANGE  MILEAGE  CHARGE  (IXC).  ALTERNATIVE  2 


included  for  later  reference  in  considering  Alternative  3.)  The  monthly  recurring  cost  (RC) 
would  be  determined  as  shown  below: 


Fixed  Charge 

:  13  x  $51.72 

= 

$ 

672 

IXC 

= 

6,645 

Drop  Charge 

:  13  x  2  x  $26.30 

= 

684 

Conditioning  Charge 

:  13  x  2  x  $15.50 

— 

403 

RC 

= 

$ 

8,404 

The  present  value  (PV)  of  the  recurring  charges  would  be: 

PV  =  $8,404  x  77.0  =  $647,108 

The  life-cycle  cost  (LC)  would  then  be: 

LC  =  OC  +  PV 

=  $320,928  +  $647,1 08  =  $.97  million 

4.3.3  Alternative  2  Back-Up  Service 

The  high  availability/reliability  of  NADIN  IA  is  provided  through  two  design  elements: 

•  multiprocessor  design  of  concentrators  and  switches,  and 

•  a  dial  back-up  system,  including  dial-up  connections  to  the  "other"  switch  should 
one  switch  be  down. 

Although  the  dial  back-up  system  would  be  a  major  improvement  over  the  NAS-NAS 
Network's  manual  back-up  system,  the  likelihood  that  the  back-up  system  would  have  to  be 
used  would  be  greater  under  Alternative  2.  This  results  from  the  increased  number  of  links 
(2  or  3)  for  each  connection  and  the  absence  of  redundant  lines  under  Alternative  2. 
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4.3.4  Alternative  2  Long-Range  Potential 


Alternative  2  provides  two  features  of  importance  to  longer-range  FAA  objectives. 
First,  there  need  be  no  dedicated  NAS  9020  input/output  ports  for  NAS-NAS 
communications.  Rather,  NAS-NAS  traffic  will  use  the  same  ports  provided  for  general 
NADIN  traffic.  This  would  greatly  facilitate  switch-over  and  testing  for  the  replacement 
computer.  Second,  under  Alternative  2  a  NAS-NAS  message  from  one  center  can  easily  be 
routed  to  any  other  center,  not  just  neighboring  centers.  This  would  greatly  facilitate 
1  support  for  almost  any  Center  Back-Up  concept. 

4.4  ALTERNATIVE  3,  ENHANCED  NADIN  ARCHITECTURE 

Alternative  3  requires  that  the  NADIN  architecture  be  modified  so  that: 

•  each  of  the  existing  CONUS  nodes  would  contain  a  concentrator  and  a  packet 

!  switch, 

•  the  Atlanta  and  Salt  Lake  City  nodes  would  also  include  message  switches, 
operating  essentially  like  the  NADIN  IA  switches  for  certain  classes  of  messages, 
and 

r 

j  •  nodes  would  be  interconnected  in  a  manner  that  would  provide  at  least  two  non- 

!  overlapping  routes  between  each  pair  of  nodes. 

r: 

[  4.4.1  Alternative  3  Throughput  Performance 

[.  Appendix  C  describes  the  analysis  performed  to  determine  a  minimal  cost  configura- 

'  tion  wivh  the  above  characteristics  that  also  satisfies  the  NADIN  and  NAS-NAS  end-to-end 

delay  constraints.  Figure  3-4  depicted  the  configuration  determined  to  be  optimal.  That 
configuration  is  made  up  of  31  links,  involving  thirty-seven  9,600  b/s  channels.  Nine  of 
those  channels  are  also  included  in  the  NADIN  IA  implementation. 
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Although  the  link  capacities  under  Alternative  3  were  selected  so  as  to  meet  delay 
constraints,  just  as  with  Alternative  2,  Alternative  3  would  have  significantly  greater 
throughput  performance.  This  is  due  to  the  availability  of  alternate  routes  between  each 
pair  of  nodes,  to  help  distribute  the  impact  of  temporary  surges  in  demand. 

4.4.2  Alternative  3  Costs 


Unlike  the  other  alternatives  analyzed,  Alternative  3  would  involve  major  modifica¬ 
tions  to  NADIN.  This  leads  to  a  number  of  unique  considerations  related  to  system  costs. 
The  most  significant  of  these  are: 

•  the  treatment  of  (unmodified)  NADIN  IA  operating  costs,  which  were  ignored 
when  considering  the  other  alternatives,  and 

•  NADIN  hardware/software  modification  costs. 


For  the  other  alternatives  it  has  been  assumed  that  the  Level  IA  implementation  of 
NADIN  would  be  retained  and  operated  regardless  of  the  alternative  selected  for  handling 
NAS-NAS  traffic.  Thus,  the  recurring  costs  associated  with  the  NADIN  IA  channels  were 
not  assigned  as  costs  for  those  alternatives;  only  the  costs  associated  with  modifications 
(additions)  were  assigned  to  pertinent  alternatives. 

The  modifications  associated  with  Alternative  3  are  not  simple  additions.  Rather 
some  items  associated  with  NADIN  IA  are  dropped  and  some  new  items  are  added.  In  order 
to  insure  comparability  between  the  costs  for  this  and  the  other  alternatives,  it  has  been 
necessary  to  determine  the  gross  recurring  cost  for  Alternative  3  and  to  reduce  that  total  by 
the  recurring  costs  of  operating  NADIN  IA  without  any  modifications. 

No  detailed  analysis  has  been  made  of  the  specific  hardware  and  software  require¬ 
ments  for  Alternative  3.  Rather,  in  order  to  obtain  a  reasonable  cost  estimate,  it  has  been 
assumed  that  an  approach  such  as  shown  in  Figure  4-1  would  be  used. 

Under  this  concept  the  original  NADIN  concentrator  hardware  would  be  retained  as 
the  network  interface  for  local  connections  (the  NAS  9020  computer,  FSSs,  FDIO  remote 
site  equipment,  etc.).  The  concentrator,  rather  than  directing  messages  to  the  Atlanta  or 
Salt  Lake  City  switch,  would  direct  all  messages  (other  than  those  that  are  locally  switched) 
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ALTERNATIVE  3  NADIN  SWITCH  CONf.FPT 


to  a  collocated  switching  module.  Modules  of  this  nature  are  available  commercially, 
complete  with  networking  software. 

The  one-time  costs  to  implement  this  concept  would  thus  include  the  cost  to  develop 
(or  purchase  and  appropriately  modify)  the  switching  modules  together  with  the  software 
and  the  cost  of  modifying  NADIN  concentrator  software.  The  former  would  cost 
approximately  $75,000  per  module;  the  latter,  including  major  testing  and  debugging,  is 
estimated  to  cost  approximately  $1.2  million. 

Based  on  the  above  considerations,  the  one-time  costs  associated  with  Alternative  3 
would  include: 

•  switching  module  costs,  including  software, 

•  modem  costs, 

•  installation  costs  for  28  new  channels, 

•  NAS  9020  software  modification  costs  (assumed  to  be  equal  to  those  for 

Alternative  2),  and 

•  NADIN  software  modification  costs. 

The  one-time  cost  (OC)  for  Alternative  3  would  thus  be  determined  as  shown  below: 


Switching  Module 

20  x  $75,000 

= 

$  1,500,000 

Modems 

2  x  15  x  $8,500 

= 

255,000 

Station  Installation 

28  x  2  x  $57 

= 

3,192 

Conditioning  Installation 

28  x  2  x  $171 

= 

9,576 

9020  Software 

400  x  $150 

= 

60,000 

NADIN  Software 

= 

1,200,000 

OC 

= 

$  3,027,768 

As  suggested  earlier,  the  recurring  cost  has  been  determined  by  considering  the 
monthly  charges  for  the  full,  modified  network  and  reducing  these  by  the  similar  charges 
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that  would  be  incurred  if  the  unmodified  NADIN  IA  were  retained.  For  the  reconfigured 
network  the  gross  recurring  cost  (GRC)  would  be  determined  as  shown  below: 

Fixed  Charge  :  37  x  $51.72  =  $  1,914 

IXC  (see  Table  4-3)  :  =  13,620 

Drop  Charge  :  37  x  2  x  $26.30  =  1,946 

Conditioning  Charge  :  37  x  2  x  $15.50  =  1,147 

GRC  =  $  18,627 

For  the  unmodified  NADIN  IA,  the  base  recurring  cost  (BRC)  would  be  determined  as  shown 
below: 


Fixed  Charge  :  22  x  $51.72  =  $  1,138 

IXC  (see  Table  4-2)  :  =  11,249 

Drop  Charge  :  22  x  2  x  $26.30  =  1,157 

Conditioning  Charge  :  22  x  2  x  $15.50  =  682 

BRC  =  $  14,226 


The  net  recurring  cost  (RC)  would  then  be: 

RC  =  GRC  -  BRC 

=  $18,627  -  $14,226  =  $4,401 

The  present  value  (PV)  of  the  recurring  charges  would  be  : 

PV  =  $4,401  x  77.0  =  $338,877 

The  life-cycle  cost  (LC)  would  be 

LC  =  $3,027,768  +  $338,877  =  $3.37  million 
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LINK  NODES 

DISTANCE 

(MILES) 

CHANNELS 

IXC 

; S/month 

Seattle 

Oakland 

67S.2 

1 

S  529.61 

Seattle 

Salt  Lake  City 

684.4 

1 

Oakland 

Los  Angeles 

323.0 

1 

29b.  5  v. 

Los  Angeles 

Salt  Lake  City 

589.7 

1 

470.60 

Los  Angeles 

Albuquerque 

673.1 

1 

l 

526.71 

Salt  Lake  City 

Albuquerque 

485.8 

1 

398.90 

Salt  Lake  City 

Denver 

359.4 

2 

623.30 

Denver 

Albuquerque 

361.6 

1 

313.20 

Oenver 

Minneapolis 

684.9 

1 

536.20 

Denver 

Kansas  City 

555.8 

2 

894.30 

Albuquerque 

Fort  Worth 

568.9 

1 

456.20 

Kansas  City 

Minneapolis 

408.3 

1 

345.40 

Kansas  City 

Fort  Worth 

437.2 

1 

365.40 

Minneapolis 

Chicago 

314.2 

1 

280.50 

Chicago 

Indianapol is 

177.9 

2 

372.80 

Kansas  City 

Memphis 

369.3 

1 

318.50 

Fort  Worth 

Houston 

222.5 

1 

217.20 

Houston 

Memphis 

473.1 

1 

390.10 

Indianapol is 

Cleveland 

232.3 

1 

223.90 

Indianapo! is 

Atlanta 

454.2 

2 

754.10 

Memph  i  s 

Atlanta 

702.2 

2 

611.80 

Houston 

Miami 

972.2 

1 

734.50 

Atlanta 

Cleveland 

558.7 

1 

449.20 

Atlanta 

Washington 

545.4 

1 

440.00 

Atlanta 

Jacksonvi lie 

232.3 

2 

447.90 

Cleveland 

Boston 

561.7 

1 

451.30 

Cleveland 

Washington 

288.0 

1 

262.40 

Washington 

New  York 

264.3 

1 

246.00 

New  York 

Boston 

158.7 

1 

173.20 

Jacksonvi 1 le 

New  York 

857.3 

1 

655.20 

Jacksonville 

Mi  ami 

356.3 

1 

309.50 

TOTALS 

37 

$13,620.00 

TABLE  4-3:  INTEREXCHANGE  MILEAGE  CHARGE  (IXC),  ALTERNATIVE  3 
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4.4.3  Alternative  3  Back-Up  Service 

Alternative  3  requires  no  separate  back-up  service.  Should  one  link  be  lost,  the  packet 
routing/switching  function  will  find  an  alternate  route  and  insure  that  no  links  are 
overloaded.  The  network  delays  under  such  circumstances  might  be  slightly  greater  than 
when  all  links  are  functioning,  but  generally  there  should  be  no  significant  degradation  in 
service  quality. 

The  fact  that  this  alternative  generally  requires  the  use  of  two  or  more  links  for  a 
connection  does  increase  the  likelihood  that  a  specific  primary  route  is  lost,  as  compared 
with  the  single  link,  redundant  NAS-NAS  Network.  Nevertheless,  the  availability  of 
alternate  routes  and  the  geographical  distribution  of  the  links  make  it  less  likely  that  a 
connection  would  be  totally  lost.  The  NAS-NAS  Network,  on  the  other  hand,  is  more 
susceptible  to  complete  loss  of  a  (redundant)  connection  as  the  result  of  storms  or  other 
external  causes. 

4.4.4  Alternative  3  Long-Range  Potential 

Alternative  3  offers  the  same  longer-range  benefits  as  Alternative  2;  i.  e.,  reduced 
computer  interfaces  and  interconnection  between  all  centers.  Alternative  3  can,  however, 
provide  generally  better  support  to  the  Center  Back-Up  concepts  in  that: 

•  it  is  less  dependent  on  routes  through  the  two  centralized  message-switch  nodes, 

•  it  provides  more  direct  connections  between  neighboring  centers,  and 

•  it  is  less  susceptible  to  link  congestion. 


4.5  ALTERNATIVE  4,  NAS-NAS/NADIN  IA 

Alternative  4  combines  the  small  network  delays  of  the  current  NAS-NAS  Network 
with  the  reduced  cost  of  using  NADIN.  Specifically,  this  alternative  retains  one  channel  on 
each  of  the  45  NAS-NAS  links  and  uses  NADIN  (as  configured  under  the  Level  IA  implemen¬ 
tation)  as  a  back-up  in  the  event  of  NAS-NAS  Network  link  outage.  An  operational  variation 
on  this  alternative  would  involve  the  use  of  NADIN  as  the  primary  communications  service 
and  the  use  of  NAS-NAS  links  only  during  periods  when  NADIN  delays  are  too  great  or  when 
there  is  a  NADIN  link  outage. 
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4.5.1  Alternative  4  Throughput  Performance 

The  throughput  performance  under  Alternative  4  would  be  essentially  the  same  as  that 
under  Alternative  1. 

4.5.2  Alternative  4  Costs 


It  is  assumed  that  under  Alternative  4  there  would  be  no  significant  modifications  to 
NADIN  IA.  NAS  9020  software  would,  however,  have  to  be  modified,  essentially  as  with 
Alternative  2.  Thus  the  one-time  cost  (OC)  for  this  alternative  would  be  determined  as 
shown  below: 

Software  :  400  x  $150  =  $60,000 


OC  =  $60,000 

The  recurring  costs  for  Alternative  4  would  be  similar  to  those  for  Alternative  1, 
however  each  link  would  now  include  only  a  single  channel.  Thus  the  recurring  cost  (RC) 
would  be  determined  as  shown  below: 


Fixed  Charge  :  45  x  $51.72  =  $  2,327 

IXC  (see  Table  4-1)  :  =  18,746 

Drop  Charge  :  45  x  2  x  $26.30  =  2,367 

Conditioning  Charge  :  45  x  2  x  $15.50  =  1,395 


RC  =  $  24,835 


The  present  value  (PV)  of  the  recurring  costs  would  thus  be: 

PV  =  $24,835  x  77.0  =  $1,912,295 

The  life-cycle  (LC)  cost  would  be  : 

LC  =  $60,000  +  $1,912,295  =  $1.97  million 
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4.5.3  Alternative  4  Back-Up  Service 


The  back-up  service  under  Alternative  4  is  NADIN  IA.  Although  this  is  better  than  the 
Alternative  1  manual  back-up  service,  it  is  more  likely  to  be  used  because  of  the  absence  of 
link  redundancy.  The  quality  of  this  back-up  service  is  generally  good;  however,  it  is  subject 
to  congestion,  if  required  during  a  peak  period. 

4.5.4  Alternative  4  Long-Range  Potential 

Alternative  4  offers  some  improvement  in  terms  of  long-range  potential  relative  to 
that  under  Alternative  1.  It  involves  only  half  as  many  interfaces  with  the  NAS  9020 
computers,  and  it  provides,  through  NADIN  IA,  interconnections  between  all  centers.  The 
fact  that  some  NAS-NAS  interfaces  would  still  exist  and  that  NADIN  link  capacities  would 
not  be  increased,  limit  the  long-range  value  of  the  improvements. 


4.6  ALTERNATIVE  5,  REDUNDANT  NADIN  IA 

Alternative  5  is  essentially  the  same  as  Alternative  2,  except  that  one  back-up  channel 
would  be  added  to  each  of  the  21  NADIN  links.  This  would  improve  service  when  primary 
channels  experience  outages.  Except  for  this  improved  back-up  service,  there  would  be  no 
significant  change  in  performance. 

4.6.1  Alternative  5  Throughput  Performance 

Under  the  basic  concept  of  this  alternative,  the  throughput  performance  would  be 
identical  with  that  of  Alternative  2.  It  should  be  possible,  however,  with  minimal  additional 
software  modifications  to  permit  use  of  the  redundant  line  at  any  time,  thus  further 
reducing  queueing  delays,  especially  during  temporary  surges  in  traffic. 

4.6.2  Alternative  5  Costs 


The  only  differences  in  cost  between  Alternatives  2  and  5  would  be  the  added  costs  of 
installation  (including  modem  purchase)  and  operation  for  the  21  back-up  channels  under 
Alternative  5.  The  added  one-time  costs  (AOC)  would  be  determined  as  below: 


Modems 

:  21  x  2  x  $8,500 

= 

$ 

357,000 

Station  Installation 

:  21  x  2  x  $57 

= 

2,394 

Conditioning  Installation 

:  21  x  2  x  $171 

= 

7,182 

AOC 

= 

$ 

366,576 

The  added  channels  for  this  alternative  basically  duplicate  the  unmodified  NADIN  1A 
channels,  except  for  the  switch-to-switch  link.  Thus  the  added  IXC  for  Alternative  5  would 
be  equal  to  that  shown  for  NADIN  IA  in  Table  4-2  minus  half  the  IXC  for  the 
switch-to-switch  link  (i.e.,  $2,010.90*2  =  $1,005).  The  added  recurring  cost  (ARC)  for 
Alternative  5  would  be  determined  as  shown  below: 

Fixed  Charge  :  21  x  $51.72  = 

IXC  :  $11,249  -$1,005  = 

Drop  Charge  :  21  x  2  x  $26.30  = 

Conditioning  Charge  :  21  x  2  x  $15.50  = 

ARC 

The  added  present  value  (APV)  of  the  recurring  costs  would  be: 

APV  =  $13,086  x  77.0  =  $1,007,622 

The  added  life-cycle  cost  (ALC)  would  be: 

ALC  =  AOC  +  APV 

=  $366,576  +  $1,007,622  =  $1.37  million 

The  total  life-cycle  cost  (LC)  would  be  obtained  by  adding  the  above  result  to  the  life-cycle 
cost  for  Alternative  2  ($.97  million),  i.e.: 

LC  =  $.97  million  +  $1.37  million  =  $2.34  million 


$  1,086 
10,244 
1,105 
651 


$  13,086 
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4.6.3  Alternative  5  Back-Up  Service 


This  alternative,  like  Alternative  1,  uses  redundant  lines  to  minimize  the  likelihood  of 
having  to  use  the  back-up  service.  Thus  these  two  alternatives  can  be  rated  equivalently  in 
this  respect. 


4.6.4  Alternative  5  Long-Range  Potential 


The  long-range  potential  of  this  alternative  is  the  same  as  that  for  Alternative  2. 
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SECTION  5 


COMPARATIVE  EVALUATION 


5.1  INTRODUCTION 


On  the  basis  of  cost  alone,  the  preceding  analysis  indicates  that  the  most  efficient 
approach  to  supporting  NAS-NAS  communications  would  involve  the  use  of  NAD1N  IA, 
enhanced  to  provide  greater  link  capacities  (Alternative  2).  The  more  subjective  portions  of 
that  analysis  indicate,  however,  that  the  higher  costs  for  the  other  alternatives  are 
generally  associated  with  additional  benefits.  This  appears  particularly  true  for  the 
Enhanced  NADIN  Architecture  (Alternative  3). 

5.2  COST  AND  BENEFIT  COMPARISONS 


The  five  alternatives  considered  for  supporting  NAS-NAS  communications  have  been 
analyzed  relative  to  four  major  areas  of  differences.  These  are: 

•  cost,  in  terms  of  the  ten-year  life  cycle  cost; 

•  throughput  performance,  reflecting  primarily  the  ability  to  effectively  handle 
temporary  surges  in  demand; 

•  back-up  service,  reflecting  the  quality  of  the  back-up  service  provided  and  the 
likelihood  that  it  would  be  needed;  and 

•  long-range  potential,  reflecting  primarily  the  ability  to  facilitate  and/or  support 
the  objectives  of  the  ATC  Computer  Replacement  Program  and  Center  Back-Up 
concepts. 

Relative  to  all  four  considerations,  no  one  of  the  five  alternatives  stands  out  as  the 
ideal  selection.  Each  has  its  advantages  and  disadvantages.  These  are  summarized  in 
Table  5-1. 


In  order  to  provide  a  more  objective  basis  for  comparison,  judgemental  values  have 
been  assigned  for  the  three  subjective  areas,  using  10  to  represent  "the  best".  The  assigned 
ratings  for  each  alternative  are  shown  in  Table  5-2  along  with  the  associated  cost. 

5.3  INTERPRETATION  OF  RESULTS 


Review  of  the  results  as  presented  in  T«»k1p  c-2  reveal  the  following: 

1.  The  major  weakness  of  the  current  NAS-NAS  network  (Alternative  1),  relative  to 
the  use  of  NADIN,  is  its  low  long-range  potential.  It  is  also  the  most  expensive 
of  the  alternatives  considered. 

2.  For  approximately  the  same  cost  as  the  current  network,  the  Enhanced  NADIN 
Architecture  (Alternative  3)  can  provide  essentially  equivalent  service  quality 
plus  a  major  increase  in  long-range  potential. 

3.  The  three  other  alternatives  involving  the  use  of  NADIN  (Altrenatives  2,  4  and  5) 
can  all  support  the  basic  NAS-NAS  requirements  at  significantly  reduced  costs. 
Each  of  these,  however,  would  involve  giving  up  other  nice-to-have  features 
when  compared  with  Alternative  3.  Only  the  redundant  NADIN  IA 
(Alternative  5),  the  most  expensive  of  the  three,  can  be  considered  to  provide 
service  (throughput  performance  and  back-up  service)  close  to  that  of  the 
current  network,  plus  a  long-range  potential  close  to  that  of  Alternative  3. 

Item  2  above  suggests  that  use  of  NADIN  would  be  preferred  over  continued  use  of  the 
current  NAS-NAS  Network.  Item  3  above  suggests  that  the  best  NADIN  alternative  depends 
on  the  cost-benefit  trade  offs.  Such  trade  offs  must  be  determined  on  a  subjective  basis, 
and  can  best  be  determined  by  FAA  personnel  more  familiar  with  FAA  priorities. 

There  are,  however,  certain  considerations  that  suggest  Alternative  3  as  the  most 
cost-beneficial  approach.  These  include: 

•  The  cost  of  the  current  NAS-NAS  Network  is  not  felt  to  be  unreasonably  high  for 
the  service  quality  provided.  Thus  cost  is  probably  one  of  the  least  important  of 
the  factors  considered. 
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SUBJECTIVE  RATINGS* 

ALTERNATIVE 

COST 

(mi  1  lions) 

THROUGHPUT 

PERFORMANCE 

BACK-UP 

SERVICE 

LONG-RANGE 

POTENTIAL 

1 .  Current 
NAS-NAS 
Network 

S3. 82 

10 

8 

2 

2.  Enhanced 

NADIN  IA 

.97 

6 

5 

6 

3.  Enhanced 

NADIN 

Architecture 

3.37 

9 

10 

10 

4.  NAS-NAS/ 

NADIN  IA 

1.97 

10 

6 

4 

5.  Redundant 

NADIN  IA 

2.34 

8 

8 

6 

♦Higher  rating  values  =  more  desirable  qualities. 


1MLE  5-2:  "‘STS  AND  SUBJECTIVE  RATINGS  FOP.  NAS-NAS  SERVICE  ALTERNATIVES 
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•  4  —v 


•  Alternative  3,  more  than  any  of  the  other  NADIN  alternatives  considered,  would 
provide  the  capability  to  support  other  more  demanding  FAA  programs  and 
communications  requirements.  Thus  a  smaller  portion  of  the  cost  for 
Alternative  3  could  be  considered  as  being  associated  strictly  with  NAS-NAS 
service.  This  concept  of  sharing  the  cost  can  best  be  evaluated  through  an 
integrated  study  (such  as  is  planned  under  Task  13). 

5.4  OTHER  CONSIDERATIONS 

The  evaluations  above  primarily  suggest  a  general  preference  for  NADIN  over  the 
current  NAS-NAS  Network.  The  identification  of  Alternative  3  as  the  most  attractive  of 
the  four  NADIN  alternatives  was  based  primarily  on  the  long-range  potential,  especially  the 
potential  for  supporting  the  ATC  Computer  Replacement  Program  and  subsequent  modifica¬ 
tions  of  the  computer  system.  Since  the  current  NAS-NAS  Network  is  expected  to  provide 
highly  satisfactory  service  prior  to  computer  replacement,  there  is  no  pressing  requirement 
to  replace  that  service.  Rather,  it  would  appear  to  be  primarily  important  that  any  change 
in  the  service  occur  prior  to  computer  replacement. 

Further,  since  the  advantages  of  Alternative  3  relate  to  its  ability  to  support  computer 
replacement  and  other  FAA  programs,  it  would  be  desirable  that  Alternative  3  be  further 
tailored  to  insure  more  optimal  support  for  those  programs.  Information  pertinent  to  this  is 
expected  to  be  developed  through  three  other  tasks  under  this  contract  (Tasks  12,  13 
and  14).  It  would  thus  appear  prudent  to  delay  any  major  activity  to  replace  the  current 
NAS-NAS  Network  until  at  least  preliminary  results  are  available  from  those  studies. 

In  anticipation  of  implementing  Alternative  3,  or  a  variation  of  that  concept,  there  are 
some  areas  of  more  detailed  study  that  should  be  addressed.  These  include: 

•  an  analysis  of  the  feasibility  and  cost  for  converting  the  NADIN  concentrators 
into  combined  concentrator /packet-switch  units; 

•  a  survey  of  other  available  hardware  and  software  to  support  -a<.  -switching 
networks  of  the  type  considered; 


•  an  analysis  of  the  impact  on  NADIN  traffic  in  general  that  would  result  from  the 
provision  of  special  handling  for  selected  message  classes  (including  use  of 
permanent  virtual  circuits  for  specific  message  classes);  and 

•  a  detailed  consideration  of  the  transition  process  from  NADIN  IA  to  the  packet¬ 
switching  enhancement. 


APPENDIX  A 


ANALYSIS  FOR  ALTERNATIVE  2 


A.l  PURPOSE  AND  SCOPE 


This  appendix  investigates  network  delay  times  for  NAS-NAS  messages,  should 
Alternative  2  be  adopted,  and  determines  modifications  necessary  to  insure  that  delay 
constraints  are  met.  It  includes  the  assumptions,  methodology  and  data  used.  This  analysis 
has  drawn  heavily  on  the  methodology  and  data  presented  in  the  Technical  Data  Package  for 
NADIN  Level  IA  (Reference  9,  referred  to  hereafter  as  the  Level  IA  Study). 

A. 2  GENERAL  APPROACH 


Under  Alternative  2,  NADIN,  essentially  as  configured  for  NADIN  IA,  would  be  used  as 
the  communications  utility  for  NAS-NAS  message  traffic.  Thus  the  traffic  between  two 
centers  would  be  routed  from  the  NADIN  concentrator  collocated  with  the  sending 
NAS  9020  computer,  to  the  associated  NADIN  switch,  and  then  to  the  NADIN  concentrator 
collocated  with  the  receiving  NAS  9020  (possibly  through  the  other  NADIN  switch). 

For  this  analysis  the  1983  peak-period  NADIN  message  traffic  identified  in  the 
Level  IA  Study  has  been  assigned  to  specific  NADIN  backbone  links.  The  projected  1983 
NAS-NAS  traffic  has  similarly  been  assigned  to  pertinent  links.  The  effect  of  these 
cumulative  throughput  requirements  on  NAS-NAS  message  delays  has  been  determined, 
using  standard  queueing  models.  Finally,  the  throughput  growth  by  1988  has  been  estimated 
and  its  effect  on  delays  also  determined. 

In  carrying  out  this  analysis,  the  following  assumptions  have  been  used: 

1.  NADIN  will  be  implemented  with  the  double-star  backbone  configuration, 
illustrated  in  Figure  A-l,  by  early  1983. 
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2.  Under  the  Level  IA  implementation,  each  NADIN  switch-to-concentrator  trunk 
will  be  a  full-duplex,  voice-grade  channel  operating  at  9,600  bits  per 
second  (b/s).  The  switch-to-switch  trunk  will  consist  of  two  such  channels. 

3.  A  switch  discipline  will  be  implemented  that  will  prevent  the  transfer  of  large 
files  from  unduly  delaying  the  transmission  of  other  messages  (as  suggested  in 
the  Level  1A  Study  and  Reference  14).  In  addition,  efforts  will  be  made  to 
restrict  the  number  of  file  transfers  that  occur  during  the  same  hour,  through 
optimal  scheduling  of  transfers  that  are  required  less  frequently  than  once  an 
hour. 

4.  In  addition  to  the  NAS-NAS  traffic,  NADIN  backbone  links  will  be  used  to 
transmit  the  following  types  of  message  traffic: 

•  NADIN  I  -  The  traffic  specified  for  initial  NADIN  implementation  (see 
Appendix  Z,  Reference  6),  including  primarily  that  traffic  currently 
handled  by  the  Area  B/Supple mental  B,  Airline  and  Military  Utility  B, 
Center  B,  AFTN  and  NASNET  networks; 

•  AFC  -  Messages  disseminated  from  the  Interim  Flow  Control  Processor 
(IFCP)  in  Jacksonville  (to  ARTCCs,  terminal  areas,  FSSs,  ARINC  and 
airlines)  under  the  Interim  Automated  Flow  Control  program  and  flight 
data  messages  forwarded  from  the  ARTCCs  to  the  Central  Flow  Control 
Computer  Complex  (CFCCC)  in  Jacksonville  (see  Reference  15); 

•  FSAS  -  All  message  and  file  transfers  identified  for  the  Flight  Service 
Automation  System  (see  Reference  14); 

•  NFDC/IS  -  NC  vMs  and  interactive  messages  transferred  between  the 
National  Flight  Data  Center  (NFDC)  in  Washington  and  the  Consolidated 
NOTAM  System  (CNS)/Airmen  Information  System  (AIS)  in  Atlanta;  plus 
NOT  A  Ms  transferred  between  the  CNS  and  a  back-up  NOTAM  processor  in 
Salt  Lake  City  (see  Alternative  2  in  Reference  16). 
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5. 


NADIN  will  also  be  used  for  other  message  traffic.  However,  such  traffic  will 
not  use  the  backbone  links;  e.g.: 


•  FDIO  (FDEP)  messages  will  be  locally  switched  by  each  NADIN  concen¬ 
trator  (as  suggested  in  the  Level  1A  Study  and  Reference  7),  and; 

•  All  traffic  between  CNS  and  AWP/WMSC  will  involve  only  the  NADIN 
Atlanta  switch;  collection  and  distribution  of  NOT  A  Ms  from  or  to  other 
locations  is  included  in  the  FSAS  and  Service  A  message  traffic  (the  latter 
is  not  considered  to  be  integrated  into  NADIN). 

6.  NADIN  backbone  traffic  to  and  from  the  three  off-shore  centers  (Anchorage, 
Honolulu  and  San  Juan)  will  have  negligible  impact  on  NADIN's  performance 
relative  to  NAS-NAS  message  traffic. 

7.  Between  the  Level  1A  implementation  (1983)  and  1988,  NADIN  message  traffic 
will  increase  in  proportion  to  the  projected  increase  in  1FR  aircraft  traffic;  this 
has  been  conservatively  estimated  to  be  22  percent. 

A. 3  THROUGHPUT  REQUIREMENTS 

Peak-period  throughput  requirements,  measured  in  bits  per  second  (b/s),  have  been 
determined  for  each  NADIN  backbone  link.  These  represent  the  accumulated  requirements 
of  the  four  traffic  categories  identified  above,  plus  the  NAS-NAS  requirements.  The 
requirements  have  been  calculated  in  two  forms: 

►  •  Net  throughput  (NT)  -  the  bits  representing  original  messages  that  are  to  be 

transmitted  per  second,  and 

•  Gross  throughput  (GT)  -  the  total  number  of  bits,  including  all  overhead 
transmissions,  that  are  to  be  transmitted  per  second. 

Both  requirements  are  calculated  from  the  average  message  length  (L,  measured  in 
characters  per  message)  and  the  peak-period  message  frequency  (F,  measured  in  messages 
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per  hour).  Net  throughput  is  the  product  of  these  two  message  characteristics,  with 
appropriate  conversion  of  units,  i.e.: 


NT  =  F  x  L  x  B/S 

where  B  =  8  =  the  number  of  bits  per  character, 

S  =  3600  =  the  number  of  seconds  per  hour. 


Thus: 


NT  =  .002222  x  F  x  L 

Gross  throughput  reflects  the  addition  of  all  other  bit,  character  and  message 
transmissions  required  by  the  network  (NADIN)  or  link  (ADCCP)  protocols.  These  have  been 
detailed  in  the  Level  IA  Study  and  are  summarized  below: 

•  NADIN  requires  a  header  and  trailer  on  each  "message".  Together  these  involve 
approximately  63  characters.  A  NADIN  message  is  limited  to  3700  characters. 
Thus,  any  actual  message  or  file  which  contains  more  than  3700  characters  must 
be  broken  down  into  two  or  more  NADIN  messages,  with  a  header  and  trailer 
added  to  each. 

•  Messages  are  transmitted  across  the  individual  NADIN  backbone  links  in  frames 
with  245  or  less  characters.  ADCCP  adds  frame  control  data,  equivalent  to 
11  characters  for  each  frame,  and  inserts  additional  zero  bits  to  avoid  ambiguity 
between  data  and  synchronization  bit  strings.  It  has  been  determined  that  the 
zero  insertion  process  increases  the  number  of  bits  (and  hence  the  number  of 
equivalent  characters)  by  about  1.6  percent. 

•  Both  the  network  and  link  protocols  transmit  control  messages  on  the  lines.  It 
has  been  estimated  that  each  adds  the  equivalent  of  3  percent  to  the 
transmissions. 
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•  Finally,  the  control  procedures  cause  the  automatic  retransmission  of  frames 
containing  transmission  errors.  It  has  been  conservatively  estimated  that 
2.5  percent  of  all  frames  must  be  retransmitted. 

Taking  these  overhead  items  into  consideration,  the  gross  message  length  (GL)  and 
gross  message  frequency  (GF)  are  determined  from: 

GL  =  [L  +  (a  x  63)  +  (b  x  11)  ]  x  1.016 

where  a  =  the  smallest  integer  ^L/3700, 

b  =  the  smallest  integer ^[L  +  (ax  63)] /245. 

GF  =  F  x  1.03  x  1.03  x  1.025 

=  1.087  x  F. 

The  gross  throughput  is  calculated  as: 

GT  =  GF  x  GL  x  B/S 

=  .00245  F  x  [L  +  (a  x  63)  +  (b  x  11)] 

The  message  characteristics  and  associated  1983  throughput  requirements  for  the  five 
traffic  categories  considered  are  presented  in  the  following  subsections. 

A.3.1  NADIN  I  Traffic 


The  Level  IA  Study  used  the  design  parameters  from  the  NADIN  Specifications 
(Appendix  Z,  Reference  6)  as  the  basis  for  NADIN  I  throughput  requirements.  That  study 
modified  only  the  Area  B  message  frequencies,  to  reflect  more  recent  data.  Those  same, 
modified  traffic  characteristics  have  been  used  in  this  analysis.  Not  included  in  those  data, 
are  the  requirements  for  the  collection  of  flight  data  from  ARTCCs  for  flow  control 
purposes.  This  function  is  now  considered  part  of  the  NADIN  I  requirements.  For 
convenience  in  this  study,  those  requirement?  re  considered  under  AFC  Traffic. 
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The  nature  of  the  NADIN  I  design  data  makes  it  impractical  to  differentiate  the 
requirements  for  individual  backbone  links.  Rather,  the  requirements  have  been  distin¬ 
guished  only  in  terms  of  three  types  of  transmissions: 

•  concentrator-to-switch, 

•  switch-to-concentrator,  and 

•  switch-to-switch. 


Table  A-l  shows  the  message  characteristics  and  the  associated  peak-period  through¬ 
put  for  each  of  these  types  of  transmission. 

A.3.2  AFC  Traffic 

The  study  of  Automated  Flow  Control  (AFC)  communications  requirements 
(Reference  15)  was  being  carried  out  simultaneously  with  the  Level  IA  Study.  As  a 
consequence  the  Level  IA  Study  reflected  preliminary  data  and  findings  relative  to  the  AFC 
message  traffic.  The  data  used  below  differ  from  that  in  the  Level  IA  Study  in  three 
respects: 

•  treatment  of  the  increase  in  number  of  pacing  airports, 

•  consideration  of  flight  data  collection  messages  (as  part  of  NADIN  I)  in  addition 
to  the  dissemination  of  flow  control  messages  (as  part  of  NADIN  IA),  and 

•  minor  revisions  to  the  flow  control  message  frequencies. 

A.3.2. 1  Pacing  Airports 

Flow  control  message  traffic  is  concerned  primarily  with  air  traffic  at  selected  busier 
airports,  called  pacing  airports.  Currently  there  are  17  pacing  airports.  This  number  is 
expected  to  increase  to  35,  sometime  between  1983  and  1988.  This  increase  is  conserva¬ 
tively  assumed  to  cause  a  doubling  in  AFC  message  traffic,  in  addition  to  increases  caused 
by  air  traffic  growth. 


NADIN  BACKBONE  LINK  MESSAGE  CHARACTERISTICS  PEAK  THROUGHPUT  (B/S) 

FROM  TO  MSG. /HR.  MEAN  CHAR.  NET  GROSS 


TABLE  A-1 :  NADIN  I  PEAK  PERIOD  MESSAGE  TRAFFIC 


For  this  analysis  it  is  convenient  to  reflect  the  impact  of  the  additional  pacing  airports 
in  the  1983  data.  Growth  in  NADIN  throughput  requirements  for  subsequent  years  can  then 
be  considered  uniform  across  the  various  message  traffic  categories. 

A. 3. 2. 2  Flight  Data  Collection  Messages 

Flight  data  messages  are  currently  directed  from  the  NAS  9020  computers  at  the  20 
CONUS  ARTCCs  to  the  CFCCC  in  Jacksonville  over  a  hybrid  store-and-forward  network. 
That  network  utilizes  selected  links  of  the  NAS-NAS  Network  to  transmit  the  messages  to 
the  NAS  9020  computers  at  five  ARTCCs  (called  forwarding  centers).  These  five  computers 
are  linked  directly  to  the  CFCCC.  Under  the  NADIN  I  implementation  the  CFCCC  will  be 
directly  connected  to  the  Atlanta  switch.  Flight  data  messages  will  then  be  transmitted 
from  each  NAS  9020  computer  to  the  collocated  NADIN  concentrator  and  then  to  the 
CFCCC  over  the  NADIN  backbone  links. 

Flight  data  message  characteristics  are  shown  in  Table  A-2.  That  table  includes  two 
groups  of  messages: 

•  Present  Messages,  i.e.,  those  currently  transmitted  over  the  store-and-forward 
network,  and 

•  Future  Messages,  i.e.,  those  additional  messages  to  be  included  in  the  flight  data 
collection  process  in  future  years. 

As  with  the  increase  in  number  of  pacing  airports,  this  analysis  includes  the  "future" 
messages  as  part  of  the  1983  throughput  requirements. 

The  baseline  (1980)  message  frequencies  have  been  obtained  from  Reference  15.  The 
projected  1983  peak  period  frequencies  have  been  determined  by  first  doubling  the  baseline 
frequencies  to  reflect  the  increased  number  of  pacing  airports,  and  then  considering  a 
3  percent  annual  growth;  i.e.: 

Adjustment  Factor  =  2  x  (1.03)^  =  2.185 
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The  data  in  Table  A-2  reflects  the  cumulative  messages  arriving  at  the  CFCCC.  The 
fraction  of  messages  that  originate  at  each  ARTCC  is  shown  in  Table  A-3  (based  on  data  in 
Reference  15)  along  with  the  associated  message  frequency. 

The  association  of  this  traffic  with  specific  NADIN  backbone  links  is  relatively  direct. 
Traffic  originating  at  a  specific  concentrator  will  exist  on  the  link  from  that  concentrator 
to  the  associated  switch  (indicated  in  Table  A-3).  The  sum  of  all  such  traffic  directed  to  the 
Salt  Lake  City  switch  will  also  exist  on  the  Salt  Lake  City  to  Atlanta  link.  This  traffic 
distribution  and  the  associated  throughput  requirements  are  shown  in  Table  A-4.  In  this  and 
subsequent  tables,  the  NADIN  links  are  identified  by  the  interconnected  nodes,  using  the 
symbols  defined  in  Table  A-3. 

A. 3. 2. 3  Flow  Control  Dissemination  Messages 

The  flow  control  message  traffic  expected  to  be  carried  by  NADIN  is  characterized  in 
terms  of  three  message  types,  all  originating  or  terminating  at  the  IFCP  in  Jacksonville. 
These  are  identified  in  Table  A-5.  Message  frequencies  shown  in  that  table  reflect  the  1980 
baseline  values  (from  Reference  15)  and  the  projected  1983  values,  obtained  by  use  of  the 
2.185  adjustment  factor  discussed  earlier.  They  apply  directly  only  to  messages  leaving  or 
arriving  at  the  IFCP. 

The  distribution  of  this  message  traffic  among  the  NADIN  links  has  been  estimated 
using  the  following  procedures  and  assumptions: 

1.  The  IFCP  will  interface  NADIN  at  the  Jacksonville  concentrator.  Thus  the 
Jacksonville-to- Atlanta  link  will  carry  all  the  Type  1  and  Type  2  traffic 
indicated  in  Table  A-5,  plus  that  portion  (5  percent)  of  the  Type  3  messages  that 
originates  at  the  Jacksonville  ARTCC. 

2.  It  has  been  estimated  that  each  Type  1  and  Type  2  message  leaving  the  IFCP, 
destined  for  ARTCCs  and  ATCTs,  will  be  addressed  to  an  average  of  five 
destinations.  The  necessary  duplication  will  be  effected  at  the  Atlanta  switch. 
Thus  there  will  be  five  times  as  many  Type  1  and  Type  2  messages  for  such 
destinations  leaving  the  Atlanta  switch  as  leaving  the  Jacksonville  concentrator. 
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ARTCC /CONCENTRATOR 

FRACTION  OF 
FLIGHT  DATA 
MESSAGE  ORIGINS** 

1983 

PEAK 

MSG. /HR. 

SYMBOL 

LOCATION 

. 

SWITCH* 

ZAB 

Albuquerque 

XLC 

.048 

766 

ZTL 

Atlanta 

XTL 

.055 

378 

ZBW 

Boston 

XTL 

.035 

559 

ZAU 

Chicago 

XTL 

.053 

846 

Z06 

Cleveland 

XTL 

.079 

1,261 

ZDV 

Denver 

XLC 

.046 

734 

ZFW 

Fort  Worth 

XLC 

.049 

782 

ZHU 

Houston 

XLC 

.036 

575 

ZID 

Indianapolis 

XTL 

.078 

1,245 

ZJX 

Jacksonvi  1  le 

XTL 

.081 

1,293 

ZKC 

Kansas  City 

XLC 

.057 

910 

ZLA 

Los  Angeles 

XLC 

.030 

479 

ZME 

Memphis 

XTL 

.067 

1,069 

ZMA 

Miami 

XTL 

.047 

750 

ZMP 

Minneapolis 

XTL 

.046 

734 

ZNY 

New  York 

XTL 

.055 

878 

ZOA 

Oakland 

XLC 

.029 

463 

ZLC 

Salt  Lake  City 

XLC 

.016 

255 

ZSE 

Seattle 

XLC 

.031 

495 

ZDC 

Washington 

XTL 

.061 

974 

*  Symbol  indicates  associated  NAD IN  switches,  as  follows: 

XlC  =  Salt  Lake  City  switch 
XTL  =  Atlanta  switch 

**  Source:  NAC  WM.303G.02  AFC  Requirements  Analysis,  December  30,  1980. 
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TABLE  A-4:  PEAK  PERIOD  AFC  FLIGHT  DATA  MESSAGE  TRAFFIC 


FLOW  CONTROL  MESSAGE  CHARACTERISTICS 


3. 


ARINC  and  airlines  will  interface  NADIN  at  the  Atlanta  switch.  Thus  messages 
to  those  destinations  will  use  only  the  Jacksonville  to  Atlanta  link. 


4.  Three  NADIN  concentrators  (New  York,  Chicago  and  Washington)  receive 
significantly  more  of  the  messages  than  the  other  17  CONUS  concentrators.  It  is 
estimated  that  11.54  percent  of  the  Type  1  and  Type  2  messages  leaving  the 
Atlanta  switch  are  routed  through  each  of  the  three  "busier"  concentrators  and 
3.85  percent  are  routed  through  each  of  the  other  seventeen  (a  3-to-l  ratio).  As 
a  result,  9  x  3.85  =  34.6  percent  are  routed  from  the  Atlanta  switch  to  the  Salt 
Lake  City  switch. 

5.  The  origins  of  Type  3  messages  are  assumed  uniformly  distributed  with  respect 
to  the  20  concentrators.  Thus,  5  percent  of  the  Type  3  messages  will  enter 
NADIN  through  each  concentrator  and  9  x  5  =  45  percent  will  be  routed  from  the 
Salt  Lake  City  switch  to  the  Atlanta  switch.  All  Type  3  messages  plus  the 
appropriate  share  (3.85  percent)  of  Type  1  and  Type  2  messages  will  be  routed 
from  the  Atlanta  switch  to  the  Jacksonville  concentrator. 

The  results  of  this  distribution  process  are  shown  in  Table  A-6. 

A.3.3  FSAS  Traffic 

The  FSAS  throughput  requirements  have  been  taken  from  the  Level  IA  Study  (as 
summarized  from  Reference  14).  In  distributing  these  requirements  to  individual  NADIN 
links,  three  categories  of  messages  have  been  considered: 

•  file  transfers, 

•  messages  to  and  from  ARO,  and 

•  all  other  messages. 

Thirteen  types  of  file  transfers  have  been  identified.  These  are  indicated  in 
Table  A-7.  All  thirteen  are  transferred  from  each  of  the  two  AWPs  (collocated  with  the 
NADIN  switches)  to  each  associated  FSDPS  (one  collocated  with  each  NADIN  concentrator). 
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TABLE  A- 7:  AWP-TO-FSDPS  FILE  TRANSFERS 


In  addition,  four  of  the  same  files  (identified  by  the  Table  A-7  footnote)  are  also  transferred 
between  the  AWPs. 

Unlike  other  message  traffic  which  occurs  essentially  at  random,  the  file  transfers  are 
scheduled.  Thus,  a  file  which  is  transferred  once  an  hour  will  be  transferred  exactly  once 
during  a  peak  hour.  A  file  transferred  once  every  eight  hours  may  or  may  not  be  transferred 
during  n  peak  hour.  If  the  file  transfers  could  be  scheduled  so  that  approximately  the  same 
number  of  file  characters  (over  a  number  of  different  files)  could  be  transferred  each  hour, 
the  average  message  frequency  shown  in  Table  A-7  could  be  used  to  determine  peak 
throughput.  Such  an  assumption  would  be  too  optimistic  for  this  analysis.  Rather,  it  has 
been  conservatively  assumed  that  the  effective  message  frequency  during  the  peak  period  is 
twice  the  average  for  those  files  scheduled  for  transfer  less  frequently  than  once  an  hour. 
This  is  indicated  by  the  Peak  Adjustment  Factor  in  the  table,  and  is  reflected  in  the 
throughput  requirements  shown. 

The  Airport  Reservation  Office  is  assumed  to  interface  NADIN  via  the  Jacksonville 
concentrator.  Thus  messages  from  an  FSDPS  to  ARO  will  be  routed  from  the  concentrator 
collocated  with  the  FSDPS,  to  the  associated  switch,  across  the  switch-to-switch  link,  if 
necessary,  and  then  from  the  Atlanta  switch  to  the  Jacksonville  concentrator.  All  messages 
from  ARO  to  an  FSDPS  would  follow  the  reverse  route.  ARO  message  traffic  is  assumed  to 
be  approximately  the  same  for  each  FSDPS.  Thus  the  data  from  the  Level  IA  Study  (and 
Reference  14)  have  been  used  for  each  link  between  a  switch  and  concentrator  (other  than 
the  Atlanta/Jacksonville  link).  The  switch-to-switch  traffic  and  the  Atlanta/Jacksonville 
link  traffic  have  been  determined  by  the  appropriate  aggregation  of  all  messages  using  those 
links. 

Data  for  other  FSAS  message  traffic  identified  in  the  Level  IA  Study  have  been  used 
directly,  assuming  essentially  the  same  level  of  traffic  between  each  FSDPS  and  associated 
AWP.  The  message  characteristics  and  resultant  throughput  requirements  for  all  three 
categories  of  messages  are  shown  in  Table  A-8. 

A.3.4  NFDC/IS  Traffic 

The  NFDC/IS  throughput  requirements  considered,  reflect  primarily  the  implemen¬ 
tation  of  Alternative  2  from  the  Communications  Support  Study  for  NFDC/IS 
(Reference  16).  That  alternative  considers  the  use  of  NADIN  backbone  links  only  for  (non¬ 
batch)  communications  between  NFDC,  connected  to  the  Washington  concentrator,  and 
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TABLE  A-8:  FSAS  PEAK  PERIOD  MESSAGE  TRAFFIC  (Page  1  of  2) 


MESSAGE  TRAFFIC 


CNS/AIS,  connected  to  the  Atlanta  switch.  Characteristics  of  that  traffic  have  been  taken 
directly  from  the  referenced  study. 

Subsequent  to  the  referenced  study,  consideration  has  been  given  to  the  use  of  a 
back-up  NOTAM  processor  in  Salt  Lake  City.  Estimates  of  the  message  traffic  between 
CNS  and  the  back-up  processor  (switch-to-swi4ch)  were  included  in  the  Level  IA  Study.  In 
order  to  ensure  a  conservative  estimate  of  switeh-to-switch  throughput  requirements,  those 
estimates  have  been  included  in  this  analysis  also.  Table  A-9  summarizes  the  message 
characteristics  and  throughput  requirements  on  the  pertinent  NADIN  links. 

A.3.5  NAS-NAS  Traffic 

NAS-NAS  traffic  characteristics  have  been  developed  on  an  origin-destination  basis 
(see  Section  2  of  this  report).  Since  the  origins  and  destinations  for  this  traffic  are  the 
NAS  9020  computers  collocated  and  interfaced  with  the  20  CONUS  NADIN  concentrators, 
the  traffic  can  be  directly  assigned  to  the  specific  links.  Table  A-10  shows  the  accumulated 
NAS-NAS  traffic  characteristics  and  throughput  requirements  for  each  NADIN  link. 

A. 3. 6  Total  Throughput 

The  gross  throughput  requirements  presented  above  for  the  various  types  of  traffic  are 
tabulated  for  each  of  the  21  NADIN  links  in  Table  A-ll.  That  table  also  shows  the  total 
requirements  for  each  direction  on  each  link. 

The  line  utilization  (U)  implied  by  these  results  is  determined  as: 

U  =  CGT/C 

where  C  =  the  line  capacity,  in  bits  per  second, 

=  9,600  b/s  for  links  between  a  switch  and  concentrator, 

=  19,200  b/s  for  the  switch-to-switch  links, 

and  CGT  =  the  cumulative  gross  throughput  on  the  link. 

Table  A-12  shows  the  throughput  requirements  and  utilization  for  the  ten  busiest  links. 
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.-12:  UTILIZATION  OF  BUSIEST  NADIN  LINKS 


A. 4  NETWORK  DELAYS 


Delays  encountered  by  NAS-NAS  messages  on  NADIN  fall  into  three  major  categories: 

•  queueing  delays  for  each  link  used, 

•  transmission  time  on  each  link,  and 

•  node  processing  delays. 

The  total  network  delay  (TD)  would  thus  be  calculated  as: 

n 

Y  (TQ.  +  TM.)  +  (n+1)  x  TN 
i=l  1  1 

the  queueing  delay  on  link  i,  in  seconds, 

the  NAS-NAS  message  transmission  time  on  link  i,  in  seconds, 
the  processing  time  per  node,  in  seconds,  and 

the  number  of  NADIN  backbone  links  involved  in  the  transmission 
(2  or  3  for  NAS-NAS  messages). 

The  processing  delay  per  node  is  conservatively  estimated  to  be  50  milliseconds,  i.e.i 

TN  =  .05  seconds 

The  transmission  time  is  determined  from: 

TMj  =  GL  x  B/Cj 

where  CL  is  the  transmission  rate  (capacity)  on  link  i,  in  bits  per  second, 

and  GL  and  B  are  the  gross  message  length  and  bits  per  character  as  discussed  earlier. 


TD  = 
where  TQ.  = 

TM.  = 

l 

TN  = 

n  = 
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For  the  links  between  a  switch  and  concentrator,  C.  =  9,600  b/s.  On  the  switch-to-switch 
link,  although  the  effective  capacity  is  19,200  b/s,  a  given  message  will  always  be 
transmitted  over  a  single  9,600  b/s  channel.  Hence,  Cj  =  9,600  b/s  for  the  dual-channel  link 
also.  Thus,  for  NAS-NAS  messages,  which  have  a  mean  length  of  37.7  characters: 

TMj  =  (37.7  +  63  +11)  x  1.016  x  8/9,600  =  .09  seconds,  for  all  links 

Using  the  above  results,  the  network  delay  can  be  expressed  as: 

n 

TD  =  (n  x  .09)  +  (n  +  1)  x  .05  +  TQ. 

i=l  1 

n 

=  .47  +  £  TQ.,  if  n  =  3 

i=l  1 

n 

=  .33  +X)  TQ.,  if  n  =  2 

i=l  1 

Determination  of  the  queueing  delays  requires  the  consideration  of  several  variations. 
Primary  among  these  is  the  presence  or  absence  of  files  to  be  transferred.  Another 
important  variation  is  the  use  of  single  or  dual  transmission  channels.  The  procedures  used 
to  estimate  the  queueing  delays  are  based  on  the  analyses  detailed  in  Reference  14. 

A.4.1  Queueing  Delays  in  the  Absence  of  File  Transfers 

On  links  involving  no  file  transfers,  messages  can  be  assumed  to  arrive  at  random.  For 
the  single-channel  links,  the  queueing  delay  will  be  approximately: 

TQ.  =  TF.  x  U./U-Uj) 

where  TFj  =  the  average  transmission  time,  in  seconds,  per  frame  on  link  i, 

=  GLF  x  B/C. 

GLF  =  the  gross  length,  in  characters,  of  an  average  frame, 

and  Uj,  Cj  and  B  are  the  link  utilization,  link  capacity  and  bits  per  character,  as 
discussed  earlier. 
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As  a  conservative  estimate,  a  full  frame  (245  characters)  is  considered  in  estimating 
TF-  Thus: 

GLF  =  (245  +  11)  x  1.016  =  260  characters 

TF.  =  260  x  8/9,600  =  .22  seconds 

U.  =  CGTj/9,600 

Uj/d-Uj)  =  CGTj/(9,600-CGT.) 


TQ.  =  .22  x  CGT./(9,600-CGT.)  seconds,  for  the  single-channel  links. 

The  above  approximation  assumes  random  (Poisson)  message  arrivals  and  a  standard 
deviation  of  frame  length  that  is  equal  to  the  average  frame  length  (a  conservative 
assumption).  The  bases  for  this  approximation  can  be  found  in  most  queueing  theory  texts 
(see,  for  example,  Reference  17,  Chapter  3). 

Files  will  be  transferred  in  both  directions  on  the  dual-channel  switch-to-switch  link. 
Peak-period  queueing  delays  for  those  links  would  thus  be  determined  as  discussed  below. 

A. 4. 2  Queueing  Delays  in  the  Presence  of  File  Transfers 

The  relatively  large  file  (or  report)  transfers  introduced  by  FSAS  and  AFC  traffic  can 
create  intervals  of  several  minutes  during  which  a  link  will  be  transmitting  at  essentially 
full  capacity.  The  assumption  of  random  message  arrival,  used  above,  is  therefore  not 
applicable  during  such  intervals.  These  intervals  will  be  the  real  peak  periods  for  NADIN. 

As  recommended  in  the  Level  IA  Study  (and  Reference  15),  it  is  assumed  that  a 
discipline  will  be  implemented  at  the  NADIN  switches,  such  that  large  file  transfers  will  not 
unduly  delay  other  message  traffic.  This  has  been  modeled  as  follows: 

•  Consider  the  NADIN  backbone  link  connecting  a  switch  (Node  A)  and  an 
associated  concentrator  or  the  other  switch  (Node  B).  For  this  link,  Node  A  will 
effectively  maintain  a  number  of  output  message  queues,  one  for  each  output 
port  at  Node  B  (plus  a  top  priority  message  queue,  which  need  not  be  considered 
here). 
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•  The  discipline  at  Node  A  will  cycle  through  the  queues  for  Node  B,  processing 
each  queue  in  turn. 

•  If  a  queue  (Queue  I)  is  empty,  it  is  instantly  passed  over. 

•  If  Queue  I  is  not  empty,  one  frame  from  that  queue  is  transmitted  to  Node  B  and 
processing  passes  to  Queue  I  +  1.  Any  other  message  frames  in  Queue  I  must 
await  processing  in  subsequent  cycles. 

The  mean  queueing  delay  for  the  first  or  only  frame  in  a  randomly  arriving  message, 
under  such  a  process  can  be  determined  approximately  as: 

TQj  =  .75  x  TCj 

where  TCj  =  mean  time  per  cycle  through  the  queues  for  link  i. 

TC.  is  determined  by  noting  that  during  the  file  transfer  interval  the  full  capacity  of 

1  t 

the  link  is  utilized  (Uj  =  1.0)  and  a  relatively  fixed  amount  of  time  (TFj )  is  devoted  in  each 
cycle  to  the  transfer  of  the  file  frame(s). 

If  U  j  is  the  utilization  associated  with  the  random  (non-file  transfer)  traffic, 

thenTF'. /TC.  =  1  -  U. 

i  i  l 

i.e.,  the  fraction  of  the  cycle  time  devoted  to  file  transfer  is  equal  to  the  fraction  of  the 
capacity  not  used  for  random  traffic. 

Thus: 


TC.  =  TFj  /(I  -  Uj ) 


! 


Uj  =  (CGTj  -  GFTj)/Cj 

where  GFTj  =  gross  throughput  requirement  for  file  transfers  on  link 
(averaged  over  the  peak  hour). 

and  CGTj  and  Cj  are  the  gross  throughput  and  capacity  for  link  i,  as  discussed  earlier. 


i 
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Combining  the  above  expressions: 


TQj  =  .75  x  TFj  x  Cj/(C.  +  GFTj  -  CGTj) 

For  the  message  traffic  considered  in  this  study,  two  "file  transfer"  queues  would 
exist,  one  for  the  scheduled  FSAS  files  and  the  other  for  the  long  (30,000  character)  AFC 
reports.  Table  A-13  summarizes  the  throughput  on  each  NADIN  link  associated  with  such 
transfers  (from  Tables  A-6  and  A-8).  The  totals  shown  in  that  table  are  the  values  for  GFT. 

i  * 

in  the  above  expression  for  Uj . 

Since  GFT.  =  0  for  most  concentrator-to-switch  links,  queueing  delay  for  those  links 
would  be  determined  as  described  in  A. 4.1  above.  Although  the  Jacksonville  concentrator  to 
Atlanta  switch  link  does  involve  file  (large  report)  transfers,  it  is  unlikely  that  a  discipline 
such  as  described  above  could  be  implemented  at  the  concentrators.  Thus  the  procedures  of 
A. 4.1  would  also  be  applicable  to  that  link. 

For  the  switch-to-concentrator  links,  both  file  transfer  queues  may  contain  frames 
simultaneously.  Thus: 

TFj  =  2  x  TF.  =  .44  seconds 

where  TF.  =  the  full  frame  transmission  time  (.22  seconds),  discussed 

earlier. 

and  TQ.  =  .75  x  .44  x  9,600/(9,600  +  GFTj  -  CGTj) 

=  3, 168. /(9, 600  +  GFTj  -  CGTj)  seconds. 

t 

Determining  TFj  for  the  switch-to-switch  links  is  not  as  direct.  Since  there  are  two 
9,600  b/s  channels,  a  randomly  arriving  message  can  be  transmitted  over  the  second  channel 
while  a  file  frame  is  being  transmitted  on  the  first.  It  is  convenient  therefore  to  treat  this 
case  as  if  there  were  a  single  19,200  b/s  channel;  i.e.: 

C.  =  19,200 

l 

TFj  =  m  x  260  x  8/19,200  =  m  x  .11 


where  m 


the  number  of  file  queues  used. 


Thus,  for  the  Atlanta  to  Salt  Lake  City  fink; 


TQ.  =  .75  x  .22  x  19,200/(19,200  +  GFTj  -  CGTj) 

=  3168/(19,200  +  GFT.  -  CGTj)  seconds. 

For  the  Salt  Lake  City  to  Atlanta  link: 

TQj  =  .75  x  .11  x  19,200/(19,200  +  GFTj  -  CGTj) 

=  1584/(19,200  +  GFT.  -  CGT.)  seconds 

A. 4. 3  Network  Delay  Summary 

The  above  expressions  have  been  used  to  determine  the  queueing  delays  for  each 
NAD1N  backbone  link,  considering  both  the  1983  and  1988  throughput  requirements.  The 
1988  requirements  have  been  approximated  as  122  percent  of  those  for  1983.  The  results  of 
these  calculations  are  shown  in  Table  A-14. 

The  queueing  delays  shown  in  Table  A-14  have  been  used  to  calculate  the  network 
delays  (TD),  as  discussed  earlier.  Thus,  for  example,  NAS-NAS  messages  transmitted  from 
Jacksonville  to  Houston  will  encounter  (in  1988): 


Node  Processing  Delays  (4  nodes)  = 

4  x  .05 

=  .20  seconds 

Transmission  Delays  (3  links)  = 

3  x  .09 

=  .27 

Queueing  Delays  (3  links): 

ZJX  to  XTL 

=  .45 

XTL  to  XLC 

=  .25 

XLC  to  XHU 

=  .55 

Total  Delay 

=  1.72  seconds 
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RANDOMLY  ARRIVING  MESSAGES 


Table  A-15  presents  some  of  the  results  obtained.  Specifically  that  table  lists  the  nine 
origin/destination  pairs  which  would  experience  the  greatest  network  delays  (as  projected 
for  1988).  Review  of  the  detailed  results  indicates: 

•  Based  on  the  1983  throughput  estimates,  34  of  the  90  NAS-NAS  connections 
(i.e.,  38  percent)  would  experience  average  peak  period  network  delays  in  excess 
of  1  second. 

•  Based  on  the  1988  throughput  estimates,  57  of  the  90  NAS-NAS  connections 
(i.e.,  63  percent)  would  experience  average  peak  period  network  delays  in  excess 
of  1  second. 

•  The  shortest  average  delay  was  found  to  occur  for  traffic  from  Salt  Lake  City  to 
Seattle  -  .84  seconds  for  1983,  .90  seconds  for  1988. 

A. 5  NADIN  IA  MODIFICATIONS 

The  above  analysis  demonstrates  that  NADIN,  as  configured  under  the  Level  IA 
configuration,  cannot  meet  NAS-NAS  delay  constraints  without  some  modifications.  Several 
techniques  are  available  for  reducing  the  expected  delays.  These  include: 

•  Using  a  separate  dedicated  channel  on  each  link  for  the  transmission  of  large 
files  and  reports; 

•  Modification  of  the  NADIN  priority  scheme,  and  hence  the  network  software,  to 
assign  NAS-NAS  messages  a  higher  priority  than  other  ATC  messages  and/or  to 
assign  large  files  and  reports  a  lower  priority; 

•  Increasing  the  capacities  of  selected  links,  by  adding  one  or  more  9,600  b/s 
channels  to  be  used  for  all  message  traffic. 
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The  first  of  the  above  techniques  would  be  the  most  expensive  since  it  involves  some 
software  modification  and  the  most  added  channels.  The  second  would  be  the  least 
expensive  since  it  involves  only  software  modifications.  Care  must  be  taken  with  that 
approach  to  insure  that  no  ATC  messages  or  files  are  unduly  delayed. 

For  purposes  of  estimating  the  cost  of  Alternative  2,  the  third  technique,  increasing 
the  capacities  of  selected  links,  has  been  assumed.  This  approach  is  the  simplest  to 
implement  and  provides  the  basis  for  a  reasonably  conservative  cost  estimate.  From  an 
analysis  of  the  detailed  delay  data,  it  has  been  determined  that  the  NAS-NAS  delay 
constraint  can  be  met  for  all  NAS-NAS  origin/destination  pairs  by  adding  one  9,600  b/s 
channel  to  fifteen  switch-to-concentrator  links.  These  specifically  include: 

•  The  10  links  between  the  Atlanta  switch  and  all  associated  concentrators  except 
the  one  at  Boston,  and 

•  The  5  links  between  the  Salt  Lake  City  switch  and  the  concentrators  at  Houston, 
Kansas  City,  Denver,  Fort  Worth  and  Salt  Lake  City. 
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NADIN  ENHANCEMENTS  TO  ACCOMMODATE  PACKET  SWITCHING 


B.l  INTRODUCTION 


B.1.1  Purpose 

This  appendix  describes  a  potential  enhancement  to  the  National  Airspace  Data 
Interchange  Network  (NADIN)  based  on  the  implementation  of  a  distributed  architecture  and 
the  employment  of  state-of-the-art  packet-switching  technology.  The  application  of  such 
technology  is  addressed  only  in  terms  of  an  evolutionary  first  step,  tailored  to  facilitating 
the  incorporation  of  Computer  B  (NAS-NAS)  message  traffic  into  NADIN. 

B.l. 2  Background 

The  trend  in  communications  support  for  large,  dispersed,  computer-based  systems  is 
toward  the  use  of  highly  connected,  distributed  networks  employing  packet-switching 
technology.  Such  a  network  appears  particularly  suitable  for  meeting  the  long  range 
requirements  for  Air  Traffic  Control  (ATC)  data  communications.  NADIN,  although  being 
implemented  essentially  as  a  centralized,  message-switching  network,  has  an  architecture 
that  can  evolve  into  such  a  packet-switched  network. 

At  the  time  NADIN  was  initially  designed,  packet-switching  technology  had  not 
reached  a  state-of-the-art  consistent  with  ATC  low-risk  requirements.  Significant  progress 
in  packet-switching  technology  and  applications  over  the  past  several  years  now  makes  such 
an  approach  a  viable  option  for  current  FAA  developments.  In  fact,  the  potential  for 
increased  capabilities  at  reduced  costs  provided  by  such  an  approach  make  packet  switching 
a  particularly  attractive  option  in  the  present  environment  of  tighter  budgets  and  increasing 
demands  on  the  ATC  system. 

The  current  study,  analyzing  communications  support  alternatives  for  the  Computer  B 
(NAS-NAS)  message  traffic,  provides  a  first  analytic  look  at  the  application  of  a  distributed, 
packet-switched  network  (DPSN)  for  ATC  communications.  This  analysis  is  not  a  full-scale 
evaluation  of  DPSN  for  all  present  and  future  ATC  applications.  Rather: 


•  it  considers  the  introduction  of  packet  switching  as  an  enhancement  to  the 
NADIN  architecture; 

•  it  only  considers  use  of  the  network  for  that  message  traffic  to  be  included  under 
the  Level  IA  implementation  of  NADIN  plus  the  NAS-NAS  message  traffic; 

•  it  does  not  address  the  detailed  architectural  changes  to  best  support  other  ATC 
requirements;  and 

•  it  does  not  address  the  network  transition  approach. 

Nevertheless,  the  analysis  (see  Appendix  C)  demonstrates  the  cost-effectiveness  of 
employing  a  DPSN  for  ATC  applications. 

B.1.3  Outline 

The  enhancements  to  the  NADIN  architecture,  envisioned  for  the  initial  implementa¬ 
tion  of  the  DPSN  concept,  are  presented  in  the  next  three  sections.  Specifically: 

•  Section  B.2  presents  a  general  overview  of  the  DPSN  concept. 

•  Section  B.3  describes  the  NADIN  IA  architecture,  as  a  basis  for  discussing 
enhancements. 

•  Section  B.4  discusses  the  enhancements  directly. 

The  final  section,  Section  B.5,  discusses  other  capabilities  and  enhancements  that  might  be 
of  interest  for  longer  range  considerations. 

13.2  CONCEPT  OVERVIEW 


General  references  to  packet-switching  technology  usually  presume  the  integration  of 
four  architectural  elements: 
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•  packet  switching; 


•  multiplexing; 

•  high  connectivity;  and 

•  distributed  control. 


Although  each  of  these  elements  can  be  implemented  independently,  the  manner  in  which 
they  complement  each  other  has  made  their  combination  a  very  desirable  approach  for 
large,  computer-based  data  communications  network  designs.  The  DPSN  addressed  by  this 
memorandum  specifically  includes  all  four  elements. 

The  general  implications  of  these  design  elements  are  discussed  below.  Their  specific 
application  for  the  enhancement  of  NADIN  is  presented  in  subsequent  sections.  A  more 
complete  discussion  of  these  concepts  can  be  found  in  Reference  18. 


Packet  Switching 


Packet  switching  is  a  method  of  operating  a  telecommunications  network  in  which 
short  message  units,  called  packets,  are  handled  independently  by  the  backbone  network.  A 
limit  on  the  size  of  a  packet  is  defined  for  the  network;  each  message  entering  the  network 
is  therefore  converted  into  one  or  more  packets,  depending  on  its  size.  In  its  simplest  form, 
packet  switching  involves  the  buffering  and  forwarding  of  the  individual  packets  by 
successive  network  nodes  along  the  transmission  path.  This  basic  concept  is  also  reflected 
in  the  link  level  ADCCP  protocol  used  on  the  NADIN  IA  backbone  links.  In  NADIN  IA, 
messages  are  transmitted  in  units  called  frames,  each  containing  a  maximum  of  245  message 
characters. 

The  major  advantage  of  packet  switching  is  that  it  facilitates  the  network's  handling 
of  traffic  from  diverse  data  terminals  and  computers  operating  at  different  speeds.  A 
broader  spectrum  of  advantages  can  be  obtained  by  combining  packet  switching  with 
multiplexing,  high  connectivity  and  distributed  control. 

Packet  switching  can  be  implemented  in  two  basic  ways  -  datagram  service  and  virtual 
circuit  service.  Virtual  circuit  service,  in  turn,  can  be  implemented  in  a  number  of  ways. 
The  X.25  standard  protocol  recommendation  (Reference  19)  supports  all  such  variations. 
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With  datagram  service,  each  packet  is  handled  independently  by  the  network.  At  each 
node  that  receives  the  packet,  only  the  next  link  on  the  packet's  journey  to  its  destination  is 
determined.  If  messages  are  divided  into  two  or  more  packets,  it  is  possible  for  successive 
packets  to  be  directed  along  different  routes  and  to  arrive  at  the  destination  out  of 
sequence.  Resolution  of  packet  sequence  must  then  be  performed  by  the  receiving 
individual,  intelligent  terminal  or  computer. 

The  major  advantages  of  datagram  service  are  that  it  requires  no  end-to-end  circuit 
set  up  and  it  provides  for  more  balanced  use  of  network  link  capacities.  Its  disadvantages 
are  the  relatively  high  overhead  in  network  control  messages  that  provide  the  nodes  the  data 
on  which  to  select  the  best  next  link,  and  the  need  for  user  sequencing  of  received  packets. 

Virtual  circuit  service  overcomes  the  packet  sequencing  problem  of  datagram  service 
by  including  mechanisms  for  packet  sequencing  within  the  network  itself.  Two  of  the  more 
efficient  techniques  that  have  been  used  to  accomplish  this  are: 

•  buffering  and  sorting  of  a  limited  number  of  packets  from  a  single  message  at 
the  last  backbone  node  to  handle  the  message;  and 

•  establishing  a  fixed  path  over  which  all  packets  from  a  single  message  will  flow 
in  sequence. 

The  former  approach  is  very  similar  to  datagram  service  in  terms  of  the  handling  of 
individual  packets.  It  does,  however,  require  additional  network  resources  for  buffering  and 
sequencing,  and  results  in  added  network  delays.  The  latter  approach  sacrifices  the 
assurance  of  balanced  link  usage  and  so  may  result  in  greater  delays  due  to  link  congestion. 
Establishment  of  a  fixed  path,  however,  can  reduce  node  processing  delays,  especially  for 
longer  messages  and  sequences  of  messages  between  two  network  users. 

Either  of  the  above  approaches  to  packet  sequencing  can  be  used  with  either  of  the 
two  major  variations  of  virtual  circuit  service  -  virtual  call  and  permanent  virtual  circuit. 
With  virtual  call  service,  a  virtual  circuit  is  established  for  the  duration  of  a  specific  "call," 
possibly  including  responses  to  the  call.  With  permanent  virtual  circuit  service,  the  virtual 
circuit  is  established  for  an  indefinite  period.  Both  variations  require  added  network 
overhead  in  order  to  set  up  and  break  down  the  virtual  circuits.  With  permanent  virtual 
circuits,  this  is  done  much  less  frequently;  however,  this  means  that  buffers  and  other 
network  resources  will  be  tied  up  even  when  not  in  use. 
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As  indicated  above,  each  of  the  various  approaches  to  packet  switching  has  advantages 
and  disadvantages.  The  optimal  approach  must  be  determined  through  analysis  of  message 
traffic  characteristics,  delay  constraints  and  available  resources. 

B.2.2  Multiplexing 

Packet  switching  would  offer  few  benefits  without  multiplexing.  Multiplexing  refers 
to  the  use  of  one  high  speed  (capacity)  communications  channel  to  handle  (essentially 
simultaneously)  messages  received  from  a  number  of  lower  speed  channels.  Standard 
techniques  include  time-division  multiplexing  (TDM)  and  frequency-division  multiplexing 
(FDM),  whereby  each  incoming  channel  is  assigned  a  specific  portion  of  the  outgoing 
channel's  resources  (transmission  time  cycle  for  TDM,  frequency  bandwidth  for  FDM). 

For  packet  switching  a  variation  of  TDM  called  statistical  multiplexing  (or  concentra¬ 
tion)  is  generally  used.  Only  one  packet  is  transmitted  over  a  backbone  channel  at  a  time; 
however,  there  are  no  fixed  time  slots.  Rather,  packets  are  interleaved,  generally  in  the 
order  they  are  received  or  generated  (barring  special  priority  considerations).  This  allows 
use  of  an  output  channel  which  has  less  capacity  than  the  sum  of  the  capacities  of  the  input 
channels.  Level  IA  NADIN  uses  this  technique  in  the  transmission  of  ADCCP  frames 
between  concentrators  and  switches. 

B.2.3  Connectivity 

A  network  is  considered  highly  connected  if  it  would  take  an  unusually  large  number  of 
simultaneous  link  outages  to  eliminate  all  communications  paths  between  any  two  nodes. 
This  is  achieved  through  a  network  topology  that  includes  direct  links  from  each  node  to  two 
or  more  other  nodes. 

NADIN  under  the  Level  I A  configuration  does  not  provide  high  connectivity.  Rather, 
it  relies  on  a  dial  back-up  service  in  the  event  of  link  outages.  The  current  NAS-NAS 
network  does  have  a  highly  connected  topology;  however,  it  does  not  provide  the  mechanism 
for  switching  the  messages  along  an  alternate  route.  Rather,  the  NAS-NAS  network  uses 
redundant  lines  between  pairs  of  ARTCCs  to  provide  back-up  service  in  the  event  of  line 
outages. 

In  addition  to  its  value  in  the  event  of  line  outages,  high  connectivity  can  also  provide 
alternate  routing  capability  to  avoid  primary  paths  that  are  congested.  This  routing 
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capability  is  generally  used  to  optimize  loading  in  packet-switched  networks.  Optimally, 
each  packet  could  be  independently  routed  over  the  path  that  instantaneously  has  the 
minimal  end-to-end  delay.  Alternatively,  a  minimal  delay  path  could  be  temporarily 
established  for  transmission  of  a  series  of  packets  between  a  given  pair  of  nodes. 

B.2.4  Distributed  Control 

Level  I A  NADIN  involves  centralized  routing  control,  in  that  most  messages  are 
directed  to  one  of  the  two  switches  for  processing  and  routing.  The  exceptions  are  the 
locally  switched  (e.g.,  FDIO)  messages  which  do  not  use  the  backbone  links. 

Completely  centralized  routing  control  for  highly  connected  networks  becomes  some¬ 
what  inefficient.  Generally,  for  such  networks,  switches  are  located  at  many  (or  all) 
backbone  nodes  and  the  routing  control  is  distributed  among  those  switches.  Some 
centralized  control  is  usually  retained  to  coordinate  the  functioning  of  the  otherwise 
independent  switches. 

Distributed  control  is  made  possible  by  the  sharing  of  link  status  and  utilization  data. 
Pertinent  data  (e.g.,  packet  queueing  delays)  are  continuously  collected  and  made  available 
to  each  switching  node.  The  nodes  use  these  data  in  conjunction  with  a  routing  algorithm  to 
update  routing  tables.  The  network  overhead  implied  by  the  collection,  distribution  and/or 
accessing  such  data  is  relatively  large.  This  is  generally  compensated  for,  however,  by  the 
increased  efficiency  of  the  resulting  routes. 

B.3  NADIN  IA  ARCHITECTURE 

The  enhancements  to  the  NADIN  architecture  being  considered  to  implement  packet 
switching  represent  a  minimum  of  changes  -  just  those  needed  for  the  efficient  support  of 
NAS-NAS  and  Level  IA  NADIN  message  traffic.  Understanding  of  the  enhanced  archi¬ 
tecture  is  thus  facilitated  by  first  reviewing  the  Level  IA  architecture  and  then  identifying 
the  changes  to  that  architecture. 

NADIN  is  currently  being  developed  as  a  centralized  network.  It  includes  two 
interconnected,  centrally  located,  message-switch  nodes.  These  are  each  connected  by  a 
star-patterned  subnetwork  to  eleven  or  twelve  concentrator  nodes.  Under  the  Level  IA 
implementation  the  link  between  a  switch  and  each  associated  concentrator  consists  of  one 
full-duplex,  voice-grade  line,  operating  at  9,600  bits  per  second  (b/s).  The  link  between  the 
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two  switches  consists  of  two  such  lines.  The  two  switches,  the  twenty-three  concentrators 
and  the  links  interconnecting  them  make  up  the  NADIN  backbone  network.  The  complete 
network  can  be  considered  to  also  include  the  various  ATC  data  terminals  and  computers 
which  use  the  NADIN  facilities  and  the  circuits  and  subnetworks  by  which  they  are  linked  to 
the  backbone  network. 

Typically,  a  NADIN  message  is  directed  from  the  originating  data  terminal  or 
computer  through  a  concentrator  to  the  associated  switch.  The  switch  then  routes  the 
message  to  its  destination  (terminal  or  computer)  by  way  of  the  other  switch,  if  necessary, 
and  the  concentrator  to  which  the  destination  is  linked.  Variations  to  this  typical  routing 
include  local  switching  at  the  concentrators  for  certain  message  traffic  and  the  entry/exit 
at  the  switches  for  message  traffic  involving  external  systems  (e.g.,  WMSC  and  International 
AFTN). 

The  NADIN  concentrators  are  intelligent  statistical  multiplexors.  Their  major 

functions  include: 

•  limited  message  processing,  e.g.,  code  and  format  conversion; 

•  local  switching  of  pertinent  traffic,  including  the  collection  and  periodic 

forwarding  of  statistics  on  such  traffic  to  the  central  switch; 

•  application  of  link-level  protocols,  including  the  fragmenting/reassembly  of 
messages  into/from  ADCCP  frames; 

•  buffering  of  messages;  and 

•  multiplexing/demultiplexing  of  message  frames. 

Each  switch  consists  of  two  major  components  -  a  front-end  processor  (FEP)  and  a 
message  processor  (DS714).  The  FEP  is  functionally  and  physically  similar  to  a  NADIN 
concentrator.  It  performs  the  actual  switching  functions.  All  links  to  the  NADIN  switch  are 
through  the  FEP.  The  DS714  is  a  computer  with  associated  peripheral  equipment  (e.g.,  tape 
and  disk  drives).  Its  functions  include: 
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message  editing; 


•  message  routing; 

•  message  recording/recovery; 

•  accounting;  and 

•  network  control. 

B.4  ENHANCED  ARCHITECTURE 


Many  of  the  NADIN  IA  architectural  elements  are  consistent  (or  at  least  not 
inconsistent)  with  requirements  for  a  DPSN  capable  of  also  supporting  NAS-NAS  message 
traffic.  In  the  first  evolutionary  step  to  implement  packet  switching,  such  elements  should 
be  retained.  As  a  result,  the  major  modifications  required  are: 

•  increased  backbone  node  connectivity; 

•  addition  of  the  packet-switching  function;  and 

•  modification  or  relocation  of  some  network  functions,  as  necessitated  by  the 
implementation  of  packet  switching  (e.g.,  the  routing  function). 

The  enhanced  architecture  is  described  in  the  following  subsections  in  terms  of: 

•  retained  NADIN  IA  elements; 

•  connectivity; 

•  backbone  nodes;  and 

•  routing/switching  functions. 
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B.4.1  Retained  NADIN  IA  Elements 


Neither  the  application  of  packet  switching  nor  the  incorporation  of  NAS-NAS  traffic 
suggests  any  reason  for  relocating  the  NADIN  backbone  nodes.  On  the  contrary,  since  the 
NADIN  concentrators  are  to  be  collocated  and  interfaced  with  the  NAS  9020s,  the 
concentrator  node  locations  are  optimal  for  NAS-NAS  support. 

The  requirement  to  provide  some  processing  and  concentration  at  the  concentrator 
nodes  will  continue  to  exist  under  the  enhanced  architecture.  In  order  to  accommodate 
additional  DPSN  functions  at  those  nodes,  any  one  of  three  options  could  be  implemented. 
These  are: 

•  enhancement  of  the  concentrators  to  perform  the  new  functions  (including 
packet  switching); 

•  replacement  of  the  concentrator  by  a  new  combination  concentrator/packet- 
switch  unit;  or 

•  addition  of  a  separate  packet-switch  module  (PSM),  retaining  the  concentrators 
and  enhancing  them  only  to  the  degree  needed  to  appropriately  interface  with 
the  PSMs. 

The  latter  of  the  above  options  is  suggested  for  the  initial  implementation  of  packet 
switching,  since  that  approach  would  have  minimal  impact  on  the  system  currently  being 
implemented.  This  approach  has  been  assumed  in  the  more  detailed  analyses  in  this  study. 

Although  not  pertinent  for  NAS-NAS  traffic,  many  NADIN  messages  would  continue  to 
require  the  message  processing  functions  provided  by  the  DS714  and  best  provided  at 
centralized  locations.  These  would  include  primarily  those  messages  which  must  be 
recorded  for  possible  retrieval,  those  to  or  from  external  systems  and  those  to  or  from  less 
intelligent  terminals,  which  require  editing  and  routing  support.  Thus  the  DS714  message 
processors  would  be  retained  under  the  enhanced  architecture.  Similarly,  the  FEPs  would  be 
retained  to  serve  as  the  front  ends  for  the  DS714s  and  as  the  gateways  for  external  systems. 

As  implied  by  the  above  discussion,  there  would  be  no  need  to  change  the  interfaces 
between  the  concentrators  and  the  various  data  terminals  and  computers  that  use  NADIN, 
nor  between  the  FEPs  and  the  external  systems.  Further,  there  would  be  no  need  to  modify 
the  basic  NADIN  message  format. 
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B.4.2  Connectivity 


Consideration  of  the  conversion  of  NADIN  into  a  DPSN  was  motivated  by  the 
NAS -NAS  requirements  for  shorter  network  delays  and  better  back-up  service  than  would  be 
available  under  the  NADIN  IA  architecture.  Higher  connectivity  for  the  NADIN  nodes  would 
be  a  major  step  in  meeting  both  of  those  requirements.  Provision  of  direct  links  between 
concentrators  at  many  adjacent  ARTCCs  would  reduce  network  (node)  processing  for  most 
NAS-NAS  messages.  The  availability  of  alternate  routes  would  reduce  possible  congestion, 
thus  reducing  delays  on  individual  links  and,  further,  would  provide  back-up  service  of 
almost  equivalent  quality  to  the  primary  service,  should  a  primary  route  link  be  out. 

In  order  to  estimate  the  cost  of  the  DPSN  approach,  a  minimal-connectivity  DPSN 
topology  has  been  determined  (see  Appendix  C).  The  criteria  used  in  determining  that 
network  included  the  following: 

•  All  links  would  consist  of  one  or  more  9,600  b/s  channels. 

•  At  least  two  non-overlapping  paths  would  exist  between  each  pair  of  packet- 
switch  nodes. 

•  The  average  network  delay  for  till  NADIN  traffic  would  be  less  than  two  seconds 
during  a  busy  hour. 

•  The  average  network  delay  for  NAS-NAS  messages  between  any  pertinent  pair  of 
origin/destination  nodes  would  be  less  than  one  second  during  a  busy  hour. 

•  Network  costs  would  be  minimized. 

The  optimal  network  topology  determined  consists  of  31  links  made  up  of  37  channels 
operating  at  9,600  b/s.  Nine  of  these  channels  are  identical  with  ones  included  under  the 
Level  IA  implementation.  The  monthly  communications  cost  for  this  configuration,  using 
the  1981  MPL  tariffs,  would  be  approximately  $4,500  more  than  for  the  NADIN  IA 
configuration.  This  compares  with  a  cost  of  approximately  $50,000  per  month  for  the 
current  NAS-NAS  network. 
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B.4.3  Backbone  Nodes 


As  suggested  earlier,  the  NADIN  1A  backbone  nodes  would  be  retained  under  the 
enhanced  architecture.  The  composition  and  function  of  the  nodes  would  be  changed, 
however;  e.g.,  PSMs  would  be  added.  Under  the  NADIN  IA  architecture,  there  are  two  types 
of  nodes: 

•  message-switch  nodes  at  the  Atlanta  and  Salt  Lake  City  ARTCCs,  which  also 
include  concentrators;  and 

•  concentrator  nodes  at  the  18  other  CONUS  ARTCCs  and  at  three  off-shore 
ARTCCs  (Anchorage,  Honolulu  and  San  Juan). 

The  enhanced  NADIN  architecture  would  result  in  three  types  of  nodes: 

•  combined  message-switch,  packet-switch  nodes  at  the  Atlanta  and  Salt  Lake 
City  ARTCCs,  which  would  also  include  concentrators; 

•  packet-switch  nodes  at  the  18  other  CONUS  ARTCCs,  which  would  also  include 
concentrators;  and 

•  concentrator  nodes  at  the  three  off-shore  ARTCCs. 

The  three  off-shore  nodes  would  remain  essentially  unchanged  for  this  initial  DPSN 
application.  This  is  practical  since  they  would  not  be  origins  or  destinations  for  any 
NAS-NAS  traffic,  it  would  be  unlikely  that  they  would  be  selected  as  part  of  alternate 
routes  for  messages  between  other  nodes,  and  they  are  not  expected  to  generate  much 
NADIN  backbone  traffic.  Each  of  the  off-shore  concentrators  would  be  linked  directly  to 
the  PSM  at  a  convenient  packet-switch  node.  Those  concentrators  would  thus  be 
functionally  modified  in  the  same  manner  as  the  other  20  concentrators. 

The  modifications  to  the  two  message-switch  nodes  are  indicated  in  Figure  B-l.  The 
major  change  is  seen  to  be  the  addition  of  the  PSM  and  the  transfer  of  the  major  switching 
function  from  the  FEP  to  the  PSM.  The  FEP  would  continue  to  serve  as  the  front  end  for 
the  DS714  and  as  a  gateway  for  external  systems.  The  concentrator  would  continue  to  serve 
as  the  backbone  network  access  point  for  ATC  data  terminals  and  computers. 
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B.4.4.2  Function  Separation 


Many  of  the  individual  functions  associated  with  routing  could  be  performed  by  either 
the  PSM  or  concentrator/FEP.  As  a  general  consideration,  the  PSM  should  be  assigned 
nearly  all  major  new  functions,  i.e.,  those  not  included  under  Level  IA  NADIN.  This  would 
minimize  needed  modifications  to  the  concentrators  and  FEPs.  However,  the 
concentrators/FEPs  would  be  responsible  for  functions  such  as  message  packetizing  and 
message  traffic  accounting,  although  these  functions  would  be  somewhat  changed  from 
similar  functions  performed  under  Level  IA  NADIN.  Further,  the  DS714  would  perform  the 
centralized  routing  control  function,  including  the  establishment  and  adjustment  of 
permanent  virtual  circuits  (if  used). 

All  functions  associated  directly  with  packet  switching  would  be  assigned  to  the  PSM. 
These  would  include  the  buffering  of  received  messages,  the  determination  of  the 
appropriate  next  link,  the  maintenance  of  routing  tables  and  the  implementation  of  packet- 
level  (level  3)  protocols.  Additional  study  would  be  required  to  determine  the  optimal 
location  of  functions  such  as  the  establishment  of  virtual  calls  and  the  association  of  service 
type  to  message  class. 

B.5  OTHER  POSSIBLE  ENHANCEMENTS 


The  enhanced  NADIN  architecture  discussed  above  represents  a  first,  minimal 
evolutionary  step  directed  to  the  accommodation  of  NAS-NAS  message  traffic  by  a  DPSN 
version  of  NADIN.  In  order  to  better  accommodate  other  types  of  traffic,  especially  those 
that  might  be  added  to  NADIN  in  the  future,  there  are  a  number  of  other  enhancements  that 
might  be  considered.  These  include: 

•  consolidation  of  PSM  and  concentrator/FEP  functions  into  a  single  hardware 
unit; 

•  conversion  of  the  three  off-shore  nodes  into  packet-switch  nodes; 

•  further  increasing  network  connectivity;  and 

•  addition  of  concentrator  nodes. 
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The  latter,  which  is  the  only  one  of  the  four  not  alluded  to  earlier,  would  involve  the 
location  of  NADIN  concentrators  near  clusters  of  ATC  data  terminals,  e.g.,  major  airports. 
Such  concentrators  could  be  linked  directly  to  the  PSM  at  the  associated  ARTCC.  This 
would  significantly  reduce  the  load  on  the  center  concentrators  and  would  most  likely 
reduce  the  communications  cost  associated  with  local  access  to  the  backbone  network.  It  is 
anticipated  thus  such  an  architectural  extention  will  be  analyzed  as  part  of  Task  3  under  this 
contract. 
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NETWORK  DESIGN  FOR  ALTERNATIVE  3 
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NETWORK  DESIGN  FOR  ALTERNATIVE  3 


C.l  PURPOSE  AND  SCOPE 


This  appendix  describes  the  analysis  performed  to  develop  an  enhanced  NADIN 
architecture  capable  of  satisfying  the  1988  performance  requirements  of  the  NADIN 
Level  IA  traffic  and  the  NAS-NAS  traffic.  It  presents  the  data  and  assumptions  used  in  the 
analysis,  and  outlines  the  methodology  employed. 

C.2  GENERAL  APPROACH 


Under  Alternative  3,  the  NADIN  architecture  would  be  enhanced  to  provide  distributed 
packet  switching.  Such  a  distributed  architecture  should,  in  comparison  with  NADIN  IA, 
result  in  greater  reliability  and  reduced  delays  achievable  for  a  given  cost.  Such  an 
architecture  could  also  serve  as  an  interim  step  in  the  expected  evolution  of  NADIN  >nto  a 
packet-switched  network  serving  all  ATC  message  traffic. 

In  determining  the  optimal  architecture  of  this  type,  the  following  assumptions  have 
been  used: 


1.  The  backbone  network  nodes  would  be  located  at  the  20  CONUS  ARTCCs  (and, 
probably,  the  3  overseas  ARTCCs). 

2.  The  20  CONUS  nodes  would  all  be  packet  switches  with  limited  message 
processing  capabilities. 

3.  Special  message  processing  functions  (performed  at  the  two  switches  under  the 
NADIN  I  and  I A  implementations)  would  be  performed  under  Alternative  3  by 
message  processors  (switches)  collocated  with  the  Atlanta  and  Salt  Lake  City 
packet  switches.  These  functions  would  include  message  recording  for  historical 
purposes  and  routing  assistance  for  messages  from  external  systems  and  less 
sophisticated  terminals. 
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These  processors  would  be  considered  as  network  hosts,  rather  than  network 
communications  nodes. 

4.  As  under  NADIN  I  and  IA,  the  20  CONUS  nodes  would  be  divided  into  two  groups 
-  11  in  the  East  group  and  9  in  the  West.  Messages  requiring  special  processing 
that  originate  at  one  of  the  East  switches  would  be  routed  to  the  Atlanta 
processor;  those  that  originate  at  one  of  the  West  switches  would  be  routed  to 
the  Salt  Lake  City  processor. 

5.  Network  links  would  consist  of  one  or  more  full  duplex,  voice  grade  lines, 
operating  at  9,600  b/s. 

6.  Node  interconnections  would  be  such  that  at  least  two  non-overlapping  routes 
exist  between  every  pair  of  nodes. 

7.  The  backbone  links  for  this  network  would  be  used  to  transmit  the  same 
categories  of  traffic  as  specified  for  Alternative  2  (see  Appendix  A);  i.e., 
NADIN  I,  AFC,  NFAS,  NFDC/IS  and  NAS-NAS. 

This  analysis  has  addressed  only  a  generalized  concept  of  a  distributed  architecture. 
As  a  result,  it  has  not  addressed: 

•  possible  relocation  of  backbone  network  nodes, 

•  changes  required  to  the  network  protocol,  and 

•  possible  changes  in  message  priority  handling. 

The  optimal  set  of  links  for  the  backbone  network  has  been  determined  with  the  aid  of 
GRINDER,  a  NAC  proprietary  package  of  interactive  network  design  programs.  The 
specific  programs  employed  were  those  that  determined  costs,  link  flows  (throughput 
routing)  and  end-to-end  delays  for  specific  network  configurations,  and  that  suggested 
configuration  changes  to  meet  end-to-end  delay  constraints.  These  applications  required  the 
following  inputs: 


network  node  locations, 


•  throughput  requirements  for  each  origin/destination  pair, 

•  tariffs  for  the  pertinent  communications  service, 

•  various  parameters  for  delay  calculations,  e.g.,  frame  length,  node  processing 
time  and  overhead  factors,  and 

•  the  delay  constraint. 

The  special  considerations  associated  with  these  inputs  are  discussed  below. 

C.3  INPUT  CONSIDERATIONS 


The  GRINDER  generalized  network  representation  includes  several  features  that  do 
not  directly  reflect  the  Alternative  3  concept.  These  limitations  and  their  resolutions  are 
outlined  below  with  reference  to  the  major  input  categories. 

C.3.1  Network  Nodes 


GRINDER  generally  requires  the  identification  and  location  of  all  terminals  and  host 
computers,  and  the  actual  or  potential  location  of  communications  facilities  (backbone 
nodes).  For  the  specific  GRINDER  programs  used,  however,  it  was  not  necessary  to  include 
the  terminals  end  hosts.  Rather  it  was  sufficient  to  identify  the  origins  and  destinations  of 
message  traffic  as  the  backbone  nodes  at  which  messages  enter  or  leave  the  network, 
respectively.  Further  it  was  assumed  that  the  backbone  nodes  would  be  located  at  the 
20  CONUS  ARTCCs. 

C.3.2  Throughput  Requirements 

Throughput  requirements  are  input  to  GRINDER  separately  for  each  origin/destination 
pair.  It  was  thus  necessary  to  translate  the  link-associated  throughput  specified  in 
Appendix  A  into  the  required  format.  The  results  of  that  effort  are  presented  in  Section  C.4 
below. 
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The  throughput  translation  process  encountered  two  major  areas  of  difficulty.  First, 
direct  specification  of  end-to-end  throughput  would  not  insure  that  pertinent  messages 
would  be  routed  through  the  message  processors.  Second,  there  would  be  no  way  of 
reflecting  the  file  transfer  considerations  discussed  in  Appendix  A.  The  former  problem  was 
resolved  by  treating  each  message  to  be  routed  through  a  message  processor  as  two 
messages  -  one  from  the  origin  node  to  the  associated  processor  node,  the  other  from  the 
processor  node  to  the  destination  node.  This  approach  affected  the  specification  of  the  end- 
to-end  delay  constraint,  discussed  later. 

The  file  transfer  considerations  outlined  in  Appendix  A  could  not  be  reflected  with 
GRINDER.  Rather,  the  conservative  file  transfer  throughput  estimates  were  treated  as 
representing  random  traffic.  This  approach  results  in  delay  estimates  that  are  low  on  links 
with  low  utilization  and  high  on  links  with  high  utilization.  The  existence  of  alternate 
routes  in  the  network  would  tend  to  make  file  transfers  appear  more  random  and  thus 
minimize  any  errors  this  approach  might  introduce. 

C. 3.3  Tariffs 

TELPAK  tariffs,  currently  applicable  for  government  leased  lines,  are  scheduled  to  be 
discontinued.  Thus  in  determining  the  relative  costs  of  various  configurations,  the  MPL 
tariffs  were  used.  These  are  discussed  in  Appendix  D.  It  was  further  assumed  that  all 
backbone  nodes  were  located  in  areas  designated  "Category  A"  under  MPL  tariffs. 

C.3.4  Delay  Parameters 

Delays  are  calculated  by  GRINDER  in  essentially  the  same  manner  as  discussed  for 
random  traffic  in  Appendix  A.  GRINDER,  however,  includes  the  node  processing  delay  only 
once  for  each  link.  Thus  GRINDER'S  calculation  of  end-to-end  delay  will  always  differ  from 
that  calculated  as  in  Appendix  A,  by  the  delay  associated  with  one  node  (.05  seconds).  This 
discrepancy  was  easily  resolved,  as  discussed  below  under  Delay  Constraint. 

GRINDER  provides  for  the  input  of  net  throughput  requirements  and  multiplicative 
link  and  network  overhead  factors.  It  was  convenient,  however,  to  input  the  gross 
throughput  values,  which  reflect  multiplicative  and  non-multiplicative  overhead  factors,  and 
to  specify  the  overhead  factors  as  zero.  This  approach  assured  greater  consistency  between 
the  analyses  for  the  separate  alternatives. 
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C.3.5  Delay  Constraint 

GRINDER  accepts  as  input  a  single  end-to-end  (network)  delay  constraint;  i.e.,  the 
maximum  acceptable  value  of  end-to-end  delay  for  the  average  frame.  Starting  from  any 
network  configuration,  it  will  attempt  to  find  the  least-cost  configuration  meeting  that 
constraint  by  adding,  deleting  and  changing  the  multiplicity  of  specific  links. 

NADIN  IA  specifications  require  an  average  peak-period  delay  of  two  seconds  or  less. 
The  NAS-NAS  traffic  requirement  is  more  severe;  the  average  delay  for  such  messages  must 
be  no  greater  than  one  second.  Further,  this  latter  constraint  is  assumed  to  apply  to  each 
NAS-NAS  origin/destination  pair,  rather  than  to  the  average  NAS-NAS  traffic  nationwide. 
The  selection  of  the  appropriate  delay  constraint  was  also  affected  by  the  need  to  treat 
some  (non-NAS-NAS)  messages  as  two  messages  within  GRINDER  and  the  bias  of  .05 
seconds  in  the  GRINDER  calculations,  as  discussed  earlier. 

In  order  to  reflect  all  of  these  considerations,  a  two  phased  application  of  GRINDER 
was  employed.  In  the  first  phase  a  distributed  network  paralleling  the  NAS-NAS  network 
was  input,  and  a  1-second  end-to-end  delay  constraint  was  specified.  GRINDER  produced  an 
"optimal"  modified  network  with  an  average  end-to-end  delay  of  approximately  1  second 
(2  seconds  for  messages  routed  through  the  processors).  Since  the  delay  constraint  applied 
to  average  message  frames,  about  half  of  the  traffic,  including  some  NAS-NAS  traffic,  had 
GRINDER-calculated  delays  greater  than  1  second. 

In  the  second  phase,  judgement  was  used  to  modify  the  GRINDER-generated  config¬ 
uration,  through  the  addition  of  links,  the  increasing  of  existing  link  capacities  and  the 
deletion  of  links  (to  keep  down  costs).  At  each  step  in  this  trial-and-error  process, 
GRINDER  was  employed  to  calculate  the  costs  and  delays  for  the  modified  design.  This 
process  was  continued  until  a  design  was  achieved  which: 

•  yielded  a  GRINDER-calculated  average  end-to-end  delay  of  less  than  .95 
seconds, 

•  yielded  no  GRINDER-calculated  delay  between  any  NAS-NAS  origin/destination 
pairs  greater  than  .95  seconds, 

•  provided  at  least  two  non-overlapping  routes  between  each  pair  of  backbone 
nodes,  and 
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•  could  not  be  further  modified  to  significantly  reduce  costs  without  violating  one 
of  the  above  conditions. 

C.4  THROUGHPUT  REQUIREMENTS 

The  throughput  requirements  associated  with  Alternative  3,  although  stated  in 
different  terms,  are  essentially  the  same  as  those  for  Alternative  2.  The  only  major 
difference  results  from  the  consolidation  of  the  two  nodes  (switch  and  concentrator)  at 
Atlanta  and  at  Salt  Lake  City  into  single  nodes.  Thus  some  traffic,  e.g.,  transmissions 
between  the  Atlanta  AWP  and  FSDPS,  would  no  longer  appear  on  backbone  links  and  would 
thus  be  ignored. 

The  1983  requirements,  stated  as  peak-period  throughput  for  each  origin/destination 
node  pair  are  presented  below,  separately  for  each  traffic  category  and  collectively  over  the 
five  categories.  All  values  shown  were  increased  by  22  percent  to  reflect  the  1988 
requirements.  The  special  considerations  and  assumptions  involved  in  translating  the  data  in 
Appendix  A  are  also  presented. 

C.4.1  NADIN  I  Traffic 

It  has  been  assumed  that  all  NADIN  I  traffic  will  be  routed  through  the  message 
processor  associated  with  the  origin  node.  Thus  most  such  messages  will  be  counted  twice, 
once  for  transmission  from  the  origin  switch  to  the  processor  switch  and  once  from  the 
processor  switch  to  the  destination  switch.  If  the  processor  switch  is  also  the  origin  or 
destinr  switch,  no  backbone  links  would  be  used  for  one  (or  both)  of  the  two 
transmissions.  Only  transmissions  using  the  backbone  links  are  considered. 

In  translating  the  NADIN  I  link  traffic  presented  in  Appendix  A,  the  following 
additional  assumption  have  been  used: 

1.  Of  the  traffic  previously  designated  as  "concentrator-to-switch,"  73  percent  is  to 
be  routed  back  to  the  originating  concentrator  or  to  other  concentrators.  The 
remaining  27  percent  is  destined  for  terminals,  computers  or  external  systems 
connected  to  the  switch.  This  breakout  is  consistent  with  the  NADIN  I  design 
data. 
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2. 


Of  the  73  percent  that  is  to  be  retransmitted  over  the  backbone  network,  an 
equal  amount  of  traffic  (collectively  from  all  concentrators)  is  to  be  forwarded 
to  each  of  the  20  concentrators. 


3.  Any  of  the  previously  designated  "switch-to-concentrator"  traffic  not  accounted 
for  above  (i.e.,  not  originating  at  one  of  the  concentrators)  is  assumed  to 
originate  at  a  terminal,  computer  or  external  system  connected  to  the  switch. 

4.  All  of  the  previously  designated  "switeh-to-switch"  traffic  is  to  be  routed  to  a 
concentrator  associated  with  the  receiving  switch  (as  opposed  to  being  destined 
for  a  terminal,  computer  or  external  system  connected  to  that  switch). 

The  results  of  applying  the  above  assumptions  to  the  data  in  Table  A-l  (Appendix  A) 
are  shown  in  Table  C-l.  Here,  and  in  subsequent  tables  and  figures  of  this  appendix,  the  20 
Alternative  3  nodes  are  designated  by  the  symbols  used  previously  to  designate  Alternative  2 
concentrators  (see  Table  A-3,  Appendix  A).  Thus,  for  example,  ZTL  designates  the  Atlanta 
switch  under  Alternative  3. 

C.4.2  AFC  Traffic 

Under  Alternative  3  it  has  been  assumed  that  no  AFC  traffic  would  be  routed  through 
the  message  processors.  Rather  all  flight  data  will  be  destined  for  the  Jacksonville  switch 
and  all  flow  control  messages  will  originate  at  or  be  destined  for  the  Jacksonville  switch. 
This  specifically  implies  that  all  message  duplication  must  be  accomplished  before  messages 
leave  Jacksonville. 

The  translation  of  the  throughput  requirements  under  Alternative  2  (Tables  A-4  and 
A-6,  Appendix  A)  to  requirements  under  Alternative  3  is  relatively  direct,  requiring 
consideration  only  of  the  traffic  originating  or  terminating  at  the  19  nodes  other  than 
Jacksonville.  The  results  of  this  translation  are  shown  in  Table  C-2,  for  Flight  Data 
Messages,  and  Table  C-3,  for  Flow  Control  Messages. 

C.4.3  FSAS  Traffic 

Each  of  the  three  FSAS  message  categories,  identified  in  Appendix  A,  involved  distinct 
considerations  in  translating  the  throughput  requirements.  These  are  summarized  below: 
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MESSAGE  CHARACTERISTICS  PEAK  THROUGHPUT  (B/S) 


NADIN  I  PEAK-PERIOD  MESSAGE  TRAFFIC 
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TABLE  C-2:  PEAK  PERIOD  AFC  FLIGHT  DATA  MESSAGE  TRAFFIC 


MESSAGE  CHARACTERISTICS  PEAK.  THROUGHPUT  (B/S) 


C-3:  PEAK  PERIOD  AFC  FLOW  CONTROL  MESSAGE  TRAFFIC 


C.4.3.1  File  Transfers 

All  file  transfers  originate  at  the  AWPs,  which  are  collocated  with  the  processor  nodes 
(Atlanta  and  Salt  Lake  City).  Thus  the  previous  "switch-to-concentrator"  file  traffic  will 
originate  at  the  processor  nodes  and  be  destined  for  the  other,  associated  (East  or  West) 
switches.  The  previous  "switch-to-switch"  file  traffic  involves  only  AWP-to-AWP  transfers; 
thus  such  traffic  involves  the  two  processor  nodes  as  origins  and  destinations  under 
Alternative  3. 

C.4.3.2  ARO  Messages 

All  ARO  messages  originate  or  terminate  at  Jacksonville.  It  is  assumed  that  these  will 
not  be  routed  through  the  message  processors.  Thus,  as  with  the  AFC  traffic,  translation  of 
such  traffic  requires  only  the  consideration  of  ARO  traffic  originating  or  terminating  at  the 
other  19  nodes. 

C.4.3.3  Other  Messages 

All  other  FSAS  messages  are  assumed  to  be  routed  through  the  message  processors. 
Most  of  these  remain  in  the  same  region  (East  or  West)  as  the  originating  node.  The 
Alternative  2  "concentrator-to-switch"  and  "switch-to-concentrator"  traffic  directly 
identifies  the  origin/destination  traffic  for  such  messages. 

Some  of  these  messages  are,  however,  exchanged  between  East  and  West  nodes.  These 
are  included  in  the  twenty-four  60-character  messages  per  hour  and  24  (of  the  459)  15- 
character  messages  per  hour  transmitted  from  each  FSDPS  (located  at  the  ARTCC)  to  the 
19  other  FSDPSs  (located  at  the  19  other  ARTCCs).  It  is  assumed  that  the  destinations  for 
such  messages  are  equally  distributed  over  the  19  other  nodes.  Thus  there  will  be 
(11  x  24)  264  messages  of  each  of  the  two  types  transmitted  to  the  Atlanta  message 
processor.  Of  these,  (10/19)  53  percent  will  be  retransmitted  to  East  nodes  and  (9/19)  47 
percent  to  West  nodes.  Thus  each  of  the  eleven  East  nodes  will  receive  (.53/11)  4.8  percent, 
and  each  of  the  nine  West  nodes  will  receive  (.47/9)  5.3  percent.  Similarly,  of  the 
(9  x  24)  216  messages  of  each  of  the  two  types  transmitted  to  the  Salt  Lake  City  processor, 
(8/19)  42  percent  will  be  retransmitted  to  West  nodes  and  (11/19)  58  percent  to  East  nodes, 
with  (.42/9)  4.7  percent  going  to  each  West  node  and  (.58/11)  5.3  percent  to  each  East  node. 
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In  translating  the  link  traffic  into  origin/destination  traffic,  it  was  thus  necessary  to 
subtract  from  the  Alternative  2  "switch-to-concentrator"  traffic  those  messages  originating 
in  the  other  section  of  the  U.S.  For  example,  the  "other"  traffic  from  the  East  processor 
(ZTL)  to  any  other  East  node  would  be  the  "switch-to-concentrator"  traffic  for 
Alternative  2,  reduced  by  the  cross-country  messages;  i.e.,  (216  x  .053)  11.4  less  messages 
per  hour  of  each  the  60-  and  15-character  messages.  These  cross-country  messages  would 
now  originate  at  the  West  processor  (ZLC). 

C.4.3.4  Summary  of  FSAS  Traffic 

Table  C-4  presents  the  results  of  translating  the  Alternative  2  FSAS  throughput 
requirements  (Table  A-8,  Appendix  A)  to  origin/destination  format.  As  with  previously 
discussed  traffic  categories,  messages  not  transmitted  over  backbone  links  are  ignored. 

C.4.4  NFDC/IS  Traffic 


All  NFDC/IS  traffic  considered  involves  transmission  between  Washington  and  Atlanta 
or  between  Atlanta  and  Salt  Lake  City.  Thus  the  Alternative  2  requirements  (Table  A-9, 
Appendix  A)  translate  directly  into  Alternative  3  requirements.  These  are  presented  in 
Table  C-5. 

C.4.5  NAS-NAS  Traffic 

NAS-NAS  throughput  requirements  were  previously  developed  in  an  origin/destination 
format.  Since  such  messages  need  not  be  routed  through  the  processor  nodes,  the  original 
data  have  been  directly  applied  for  Alternative  3  analysis.  These  are  presented  in 
Table  C-6. 

C.4.6  Total  Throughput  Requirements 

The  requirements  identified  above  have  been  accumulated  for  each  pertinent 
origin/destination  pair  in  Tables  C-7  and  C-8.  Table  C-7  presents  all  traffic  with  origin  or 
destination  at  one  of  the  three  busiest  nodes  -  Atlanta,  Salt  Lake  City  and  Jacksonville. 
This  includes  all  of  the  requirements  except  some  of  the  NAS-NAS  traffic.  The  remaining 
requirements  are  presented  in  Table  C-8. 
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TABLE  C-4:  FSAS  PEAK  PERIOD  MESSAGE  TRAFFIC  (Page  1  of  3) 
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TABLE  C-7:  CUMULATIVE  PEAK  PERIOD  MESSAGE  TRAFFIC  FOR  BUSIEST  NODES 


TABLE  C-8:  CUMULATIVE  PEAK  PERIOD  MESSAGE  TRAFFIC  FOR 
OTHER  ORIGIN/DESTINATION  PAIRS 
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C.5  OPTIMAL  CONFIGURATION 


The  optimal  configuration  determined  for  the  Alternative  3  network  concept  is  shown 
in  Figure  C-l.  This  configuration  interconnects  the  20  nodes  with  31  links,  six  requiring  two 
9,600  b/s  lines,  the  remainder  requiring  single  9,600  b/s  lines. 

The  optimized  routing  of  all  1988  traffic  suggested  by  GRINDER  results  in  link  delays 
(ignoring  all  node  processing  delays)  shown  in  Table  C-9.  The  end-to-end  delays  for  all 
90  NAS-NAS  origin/destination  pairs  have  been  computed.  The  16  origin/destination  pairs 
with  the  greatest  delays  are  shown  in  Table  C-10  (including  all  node  processing  delays). 
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C_1 .  OPTIMAL  ALTEPM&TTVE  3  CONFIGURATION 


LINK  NODES 


LINK  DELAY  (SEC.)  FROM: 


A 

B 

A  to  B 

ZOA 

.14 

.11 

ZLC 

.14 

.43 

ZOA 

ZLA 

.12 

.  C 

ZLA 

ZLC 

.15 

.77 

ZLA 

ZAB 

.17 

.18 

ZLC 

ZAB 

.85 

.18 

ZLC* 

ZDV* 

.48 

.12 

ZDV 

ZAB 

.16 

.15 

ZOV 

ZMP 

.14 

.11 

ZDV* 

ZKC* 

.19 

.12 

ZAB 

ZFW 

.41 

.24 

ZKC 

ZMP 

.14 

.10 

ZKC 

ZFW 

.15 

.11 

ZMP 

ZAU 

.18 

.24 

ZAU* 

ZIO* 

.11 

.16 

ZKC 

ZME 

.38 

.55 

ZFW 

ZHU 

.27 

.26 

ZHU 

ZME 

.11 

.25 

ZID 

ZOB 

.16 

.12 

ZIO* 

ZTL* 

.11 

.36 

ZME* 

ZTL* 

.12 

.33 

ZHU 

ZMA 

.20 

.17 

ZTL 

ZOB 

.54 

.17 

ZTL 

ZOC 

.61 

.18 

ZTL* 

ZJX* 

.37 

.19 

ZOB 

ZBW 

.22 

.13 

ZOB 

ZDC 

.12 

.11 

ZDC 

ZNY 

.21 

.21 

ZNY 

ZBW 

.15 

.12 

ZJX 

ZNY 

.48 

.13 

ZJX 

ZMA 

.42 

.21 

*  Indicates  dual  -  9,600  b/s  links. 


TABLE  C-9;  ALTERNATIVE  3  LINK  DELAYS 
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ORIGIN  DESTINATION  |  END-TO-END  DELAY  (SEC. 


CO  C\J  CVI  T— <  •— 4 

I —  i — 


o  fs  imnnro 

f"*  LO  LO  LD 


<U>Q-  D 

— j  o  z  s  m 

rvj  rvj  rxj  rvj  rvj 


ID  a.  C  o  o 
XSO^Q 
N  NJ  N  N  N 


<  3  QOUQ  Q 
3EI  UU  O  *— < i  *— I I 

r^l  rvi  rsj  r^j  r^j 


O  x  <  o  — i 
-ID  21  JI¬ 
NN  N  N  N 


X  CQ  U  Q  _ I 

cn  r^j  rN  rvi  cn 


>  IJJ  Q.  UJ  UJ  O 

Z  2:  2:  S  Z  y 

rvj  rsj  rxj  rvi  r^si  rvi 


TABLE  C-10:  MAXIMUM  DELAYS  FOR  NAS-NAS  TRAFFIC 
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COST  ANALYSIS  METHODOLOGY  AND  DATA 


D.l  PURPOSE  AND  SCOPE 

This  appendix  presents  the  general  methodology  used  to  estimate  the  cost  of  the 
various  alternatives  for  supporting  NAS-NAS  communications.  The  methodology  has  been 
designed  to  provide  results  that  can  be  directly  compared,  despite  the  many  unique 
considerations  pertinent  to  individual  alternatives.  This  appendix  also  presents  the  common 
data  (parameter  values)  used  to  implement  the  methodology. 


D.2  COMPARABILITY 

The  intent  of  the  methodology  is  to  produce  for  each  alternative  a  single  cost  estimate 
that  can  be  directly  compared  with  the  cost  estimates  for  all  of  the  other  alternatives.  In 
analyzing  the  various  alternatives  for  supporting  NAS-NAS  communications,  achieving 
comparable  costs  requires  careful  attention  to  three  areas  of  complexity: 

1.  the  aggregation  of  one-time  and  recurring  costs; 

2.  the  treatment  of  costs  for  systems  that  currently  exist  (or  would  be  procured 
regardless  of  the  alternative  selected),  but  would  be  eliminated  by  one  or  more 
of  the  alternatives;  and 

3.  the  treatment  of  costs  for  excess  NADIN  communications  capacity,  available 
before  or  after  the  incorporation  of  the  NAS-NAS  services. 

The  manner  in  which  these  three  areas  have  been  handled  essentially  defines  the  cost 
methodology  employed.  Each  is  discussed  separately  below. 


D.2.1  Life-Cycle  Costs 

One-time  costs  refer  to  expenditures  for  items  such  as  hardware  purchase,  software 
development  and  systems  installation.  Such  items  are  generally  considered  to  occur  and  be 
paid  for  when  the  system  is  implemented  or  modified.  If  the  new  or  modified  system  is 
expected  to  have  a  long  life,  some  of  these  items  will  reoccur;  for  example,  worn-out 
equipment  would  have  to  be  replaced  by  newly  purchased  equipment. 

Recurring  costs  refer  to  expenditures  for  such  items  as  equipment  leasing  and  system 
maintenance.  Such  items  occur  on  a  regular  or  (frequent)  as-needed  basis.  For  cost  analysis 
they  are  considered  to  be  paid  for  in  fixed  amounts  (ignoring  inflation)  at  regular  time 
intervals  (e.g.,  once  a  month). 

Because  of  the  different  time  factors  involved,  one-time  and  recurring  costs  cannot  be 
directly  added.  This  is  generally  handled  by  defining  the  system's  lifetime  and  then 
including  each  cost  item  as  often  as  it  is  expected  to  occur  over  one  life-cycle.  For  this 
analysis  a  lifetime  of  10  years  (120  months)  is  assumed. 

Another  important  difference  between  one-time  and  recurring  costs  is  that  a  dollar 
spent  today  effectively  costs  more  than  one  spent  next  year  (ignoring  inflation).  This  is  so 
because  a  dollar  spent  today  either  must  be  borrowed,  implying  interest  costs,  or,  if  already 
available,  cannot  be  invested,  implying  lost  interest  payments.  This  difference  is  generally 
resolved  by  calculating  the  present  value  of  recurring  costs  (and  of  one-time  costs  that 
occur  at  a  later  time).  The  present  value  can  be  thought  of  as  the  amount  of  money  that 
would  have  to  be  invested  at  the  start  in  order  that  the  combined  principal  and  interest 
would  exactly  pay  all  the  future  costs,  when  due,  over  the  life-cycle  of  the  system.  Such 
costs  could  be  added  directly  to  the  initial  one-time  costs. 

Standard  models  exist  for  estimating  present  values  of  future  costs.  Because  of  the 
limited  lifetime  of  the  systems  being  considered,  all  one-time  costs  are  assumed  to  be 
expended  only  in  1983  (Subsection  D.2.2,  below,  includes  discussion  of  pre-1983  costs).  The 
1 983  present  value  of  the  recurring  costs  can  be  calculated  using: 


PV  = 

RC  x  (1-  (1+D)  "m)/D 

where 

PV  = 

the  present  value,  in  dollars. 

RC  = 

the  recurring  costs,  in  dollars  per  month, 
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m  -  the  system  lifetime,  in  months, 

and  D  =  the  effective  cost  of  money,  on  a  monthly  basis. 

If  inflation  is  ignored,  D  would  be  the  monthly  interest  (or  discount)  rate.  If  inflation  is  to 
be  considered,  D  would  be  determined  as: 

D  =  1  -  (1+I)/(1+F) 

where 

I  =  the  monthly  interest  rate, 

and  F  =  the  monthly  inflation  rate. 

For  this  analysis  D  is  taken  to  be  .008  per  month  (.10  per  year)  and  m  is  taken  as  120 
months.  Thus: 

PV  =  RC  x  77.0 

D.2.2  Existing  Systems 

It  is  assumed  for  this  analysis  that,  regardless  of  which  alternative  for  NAS-NAS 
communications  support  is  implemented,  the  NAS-NAS  Network  would  be  operated  through 
the  beginning  of  1983,  and  that  NADIN  Level  IA  would  be  implemented  by  1983.  Thus  any 
costs  associated  with  those  systems  prior  to  1983  would  be  the  same  for  all  alternatives,  and 
thus  need  not  be  considered  in  determining  comparative  costs. 

The  NAS-NAS  Network  would  be  retained  in  some  form  only  under  Alternatives  1 
and  4.  Thus  all  costs  associated  with  the  continued  operation  of  that  network  (as  modified, 
under  Alternatives  4)  must  be  included  only  in  analyzing  those  two  alternatives. 

NADIN,  on  the  other  hand,  would  continue  to  be  operated  under  all  five  alternatives, 
including  in  particular  Alternative  1.  It  is  convenient,  therefore,  to  consider  the  cost  of 
continuing  to  operate  the  NADIN  Level  IA  implementation  as  a  common  cost  for  all 
alternatives,  and  thus  to  (generally)  ignore  that  cost  in  the  analysis.  Thus,  for  example, 
Alternative  2  costs  need  include  only  the  one-time  and  recurring  costs  associated  with 
increases  in  link  capacities.  This  approach  cannot,  however,  be  directly  applied  to 
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Alternative  3,  since  the  network  architecture  would  be  significantly  modified.  In  order  to 
be  consistent,  the  total  cost  associated  with  the  Alternative  3  modifications  and  operation 
must  be  determined.  Then,  in  order  that  the  cost  be  comparable  to  that  for  the  other 
alternatives,  it  must  be  reduced  by  the  cost  of  continuing  to  operate  NADIN  under  the 
Level  IA  implementation. 

D.2.3  Excess  Capacity 

In  order  to  insure  a  robust  communications  system,  links  are  designed  with  capacities 
in  excess  of  those  required.  Thus,  for  example,  under  Alternative  2  some  of  the  NADIN  IA 
links  would  be  able  to  absorb  the  NAS-NAS  traffic  without  an  increase  in  capacity.  Further, 
for  those  links  that  require  an  increase,  capacity  would  be  added  in  increments  of  9,600  b/s, 
even  though  this  may  be  well  in  excess  of  that  required.  This  approach  is  generally 
practical,  since  the  only  significant  cost  difference  between  a  2,400  b/s  and  9,600  b/s  line  is 
the  cost  of  the  modems  required  to  interface  the  lines  with  the  communications  node 
equipment. 

With  an  evolving  system  such  as  NADIN,  it  is  very  likely  that  the  excess  capacity 
would  ultimately  be  consumed  in  servicing  other  FAA  requirements,  just  as  the  NAS-NAS 
traffic  could  consume  some  or  all  the  excess  link  capacity  provided  under  the  Level  IA 
implementation.  Two  basic  approaches  would  be  generally  applicable  for  considering  the 
costs  associated  with  excess  NADIN  link  capacities.  These  are: 

1.  Marginal  Costs  -  i.e,  consider  the  full  cost  associated  with  increasing  link 

capacity  and  consider  any  previously  excess  capacity  as 
free. 

2.  Pro  Rated  Costs  -  i.e.,  assume  that  all  capacity  available  on  a  link  would 

ultimately  be  used  (regardless  of  NAS-NAS  support 
alternative  implemented).  Then  assign  as  a  cost  to 
NAS-NAS  support  only  a  pro  rata  share  for  the  capacity 
expected  to  be  used,  be  that  on  a  previously  existing  line 
or  a  line  to  be  added. 

For  this  analysis  approach  1,  marginal  costing,  has  been  adopted. 
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D.3  TARIFFS 


A  significant  element  in  the  costs  for  all  five  alternatives  are  the  charges  by 
commercial  carriers  for  providing  leased  line  service.  For  this  analysis  it  is  assumed  that 
the  Multi-Schedule  Private  Line  (MPL)  tariffs  apply  to  both  the  NAS-NAS  Network  and  the 
NADIN  backbone  network.  Further,  it  is  convenient  to  assume  that  all  backbone  nodes  (the 
20  ARTCC.')  are  located  in  areas  designated  "Category  A"  under  those  tariffs. 

The  MPL  tariffs  include  four  major  categories  of  charges.  These  are: 

1.  Station  Terminal  Charges,  including  a  one-time  installation  charge  of  approxi¬ 
mately  $57  per  drop  (i.e.,  $114  per  point-to-point  channel),  and  a  recurring  cost 
of  $26.30  per  drop  per  month; 

2.  Fixed  Charges  of  $51.72  per  channel  per  month; 

3.  Interexchange  Mileage  Charges,  shown  in  Table  D-l; 

4.  Channel  Conditioning  Charges,  including  an  installation  charge  of  approximately 
$171  per  drop,  and  a  recurring  cost  of  approximately  $15.50  per  drop  per  month. 

D.4  OTHER  COST  CONSIDERATIONS 


Most  of  the  other  cost  considerations  are  pertinent  only  to  the  individual  alternatives. 

Those  that  are  of  more  general  concern  are  indicated  below: 

1.  Modems  required  at  each  end  of  9,600  b/s  lines  cost  approximately  $8,500 
apiece. 

2.  The  only  significant  cost  associated  with  channels  between  a  collocated  N'ADIN 
switch  and  concentrator  is  the  cost  of  modems  or  other  interface  adaptors.  Such 
equipment  will  generally  be  much  less  expensive  than  modems  required  for  the 
long  distance  leased  lines.  For  this  analysis,  however,  two  $8,500  modems  are 
assumed  to  be  required  for  each  such  channel  also. 

3.  Software  development  will  cost  approximately  $150  per  instruction. 
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at. 


MILES 


COST/MILE/MONTH 


0  -  15 
16  -  25 
26  -  100 
100  -  1,000 


$1.89 

1.58 

1.18 

.69 


over  1,000 


.42 


1.  Rates  shown  are  based  on  MPL  tariffs  for  channel 
between  two  Category  A  locations. 


2.  Example 

calculations  - 

250  mile 

channel : 

15 

miles 

<a 

1.89  = 

$28.35 

10 

miles 

1.58  = 

15.80 

75 

miles 

1.18  = 

88.50 

150 

miles 

.69  = 

103.50 

TOTAL  250 

miles 

= 

$236.15 

TABLE  D-l:  INTEREXCHANGE  MILEAGE  RATES 
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